













































































































































A Testbed For The Imagination 



Simulation and modeling 
software for designing 
large, complex systems. 


Reader Service Number 1 


System complexity... ever increasing, it requires sophisticated 
tools for its management. And, as complexity increases, the costs 
of flawed design decisions increase with it. 

If you design... complex hardware systems, software systems, 
communications systems, or VLSI circuitry, you know the 
consequences of discovering a subtle flaw late in the develop¬ 
ment cycle. 

What if. ..you had an easy to use, elegant tool that could 
determine the impact of design decisions when they are made, 
not weeks or months later? 

Introducing. ..a multi-level simulation, modeling, and design 
evaluation tool that will let you test your ideas, not regret them: 
SES /workbench. 

Call 512-474-4526, write to us 
or check the reader response 
card for more information. 


Test the design , not just the e 

Scientific and Engineering Software, 
1301 West 25th, Suite #300, Austin, 3 
Phone: 512/474-4526 Fax: 512/479-6 
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NEW FOR LAN PLANNERS 



Realistic simulation of your Local Area Network, quick results 
-no programming 


SIMLAN II now predicts performance of LAN’s 

Free trial and, if you act now, free training 


S IMLAN II uses simulation 
to predict your LAN perfor¬ 
mance. You simply describe your 
LAN and workload. 

Animated simulation follows im- 
mediately-no programming delays. 

Easy-to-understand results 

You get an animated picture of 
your LAN. System bottlenecks and 
changing levels of utilization are ap¬ 
parent. 

You can model clients, servers, 
bridges and gateways. 

Your reports show system 
statistics such as transfer times, 
information throughput, and 
message loss. Client, server, and 
gateway statistics show queue 
lengths, waiting times, and block¬ 
ing. 

Computers with SIMLAN II 

SIMLAN II is available for most 
PC’s and Workstations. 


Your network simulated 

You can predict the performance 
of any LAN. Industry standard 
protocols such as Ethernet, Token 
Ring, Token Bus, and FDDI are 
built-in. Others can be modeled. 

You can easily study the effect of 
changing parameters or even pro¬ 
tocols. 

Seeing your LAN animated in¬ 
creases everyone’s understanding of 
its operation and builds confidence 
in your results. 

Free trial information 

The free trial contains everything 
you need to try SIMLAN II™on 
your computer. For a limited time 
we also include free training 
-no cost, no obligation. 

Call Paul Gorman at (619) 
457-9681, Fax (619) 457-1184. In 
Europe, call Richard Eve on (01) 
528-7980, Fax (01) 528-7988. 


Free trial offer 


Limited offer-Act now for free training. 

□ Send information on your Special 
University Offer. 
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Return to: 

CACI Products Company 

3344 North Torrey Pines Court 

La Jolla, California 92037 IEEE co 

Call Paul Gorman at (619) 457-9681. 
Fax (619) 457-1184. 

In Europe: 

CACI Products Division 
Regent House, 89 Kingsway 
London WC2B 6RH, United Kingdom 
Call Richard Eve on (01) 528-7980. 

Fax (01) 528-7988. 
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53 Graphical Configuration Programming 
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This workstation integrates the textual and graphical information required for configuration programming. Its editing, monitoring, 
layout, and control facilities are applied dynamically to operational systems. 
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President’s MESSAGE 


Standards: Preparing for the technology of the 1990s 




Kenneth R. Anderson 


Paul L. Borrill 


W ith more than 160 working 
groups in areas from hard¬ 
ware testing to networking, 
communications, and languages, the 
Computer Society is playing an active, 
global role in standards development. 
This month, Paul Borrill, vice president 
for standards, explains the standards ac¬ 
tivities that are helping us manufacture 
and use computers more efficiently. 

Kenneth R. Anderson 
President 


tandards development in the IEEE 
Computer Society continues to 
grow at a breathtaking pace, and 
recognition by industry of its signifi¬ 
cance is greater now than it has ever been. 

Previously, many of the innovative go- 
getters in our modem technological soci¬ 
ety had a negative image of the standardi¬ 
zation process. It was seen as slow work 
done by procrastinating committees that 
published their documents long after the 
technology involved had become obsolete. 

The Computer Society has changed 
this image dramatically. Recognizing 
and embracing the accelerated pace of 
computer technology. Computer Society 
members pioneered a new style of stan¬ 
dardization process that concentrates less 
on politics and more on technical results. 
Our successes have been significant: 

• A single, worldwide standard for the 
format and behavior of floating-point 
numbers allows scientists and engineers 
to perform calculations and exchange 
data in ways that are consistent and re¬ 
peatable. 

• A community of professionals, 


which meets three times yearly, concen¬ 
trates on the immensely difficult problem 
of computer communications. This IEEE 
802.x group is responsible for creating 
the standards that allow computers to 
communicate. Local-area, wide-area, 
and now metropolitan-area networks are 
changing our perspective of this global 
village in which we live. 

• Software portability, once the bane 
of the computer industry, is one step 
closer to becoming a reality. IEEE 1003.x 
Posix, which provides the interface com¬ 
patibility for programs running under 
Unix-based operating systems, has be¬ 
come the computer industry's most re¬ 
cent success story. New activities include 
standardization of user interfaces to the 
operating system. 

• Backplane buses, the IEEE standards 
for interconnecting boards within a com¬ 
puter, have generated a multi-billion- 
dollar market, both for add-in boards and 
for system vendors who need to use off- 
the-shelf parts to put together special- 
application computers. IEEE standards 
are used in personal computers such as 
the Macintosh II series, and the Future- 
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bus+ will be used in mission-critical com¬ 
puters for the US Navy. 

To many engineers and corporate plan¬ 
ners who buy and use computers as tools 
for their businesses, the benefits of stan¬ 
dardization are obvious. To engineers 
and executives in companies on the sup¬ 
ply side of the equation, however, stan¬ 
dards are counter-intuitive and are often 
treated as an undesirable necessity for 
doing business rather than as an opportu¬ 
nity to build a bigger pie for everyone’s 
benefit, including their own. Many tradi¬ 
tional computer companies have been 
slow to grasp the immense attractiveness 
of standards to users. Instead, they’ve 
tried to enforce customer loyalty to their 
products by creating incompatibility bar¬ 
riers. Recently, start-up computer and 
workstation manufacturers offering a 
wide range of products based on open 
standards — building Ferraris with off- 
the-shelf parts — have risen with breath¬ 
taking speed. The message to the industry 
is clear: Give the users what they want; 
tear down the tower of Babel. 

Despite the Computer Society’s suc¬ 
cesses, of which we can justly feel proud, 
problems remain. Truly successful stan¬ 
dards working groups are still in the mi¬ 
nority. A common trait among the suc¬ 
cessful groups is the organizational and 
management skill of their leaders. Some¬ 
times these skills are brought to the group 
by an experienced person, but more often 
these skills are learned on the job, as dedi¬ 
cated individuals find out for themselves 
the value of managing by objective, set¬ 
ting milestones, giving recognition, and 
achieving consensus. The art and science 
of managing volunteers is considerably 
less developed than that of managing 
those who report to us professionally, but 
we are learning. We now need to pass that 
knowledge on to all our working groups. 
Thus, the Standards Activities Board is 
working on a standards development guide 
and developing seminars on standards 
process management for early 1990. 

For the future, our vision is to recog¬ 
nize and broaden our strengths — primar¬ 
ily, the consensus process, based on the 
one-person, one-vote principle. All IEEE 
working groups are open in the most fun¬ 
damental sense of that word: Anyone can 
attend meetings; majority rule prevails, 
but minority rights and individual dignity 
are protected and assured. Adhering to 
these principles — and providing a logical 
order of business — will enable group 
progress toward the goal of delivering 
excellent specifications to the market¬ 
place to establish industry standards of 
real value. 

Paul L. Borrill 

Vice President for Standards 
October 1989 
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■ Eiffel 

The Object-Oriented Language 
for Today and Tomorrow 


So you’re looking for reliability, reusability, and 
maintainability - so you know you need an object-oriented 
language - and you want the very best. A language which 
will stand the test of time - ask around, you’ll hear Eiffel 
over and over again. And for very good reason. 

Eiffel is the industrial application of modern software 
engineering techniques. It offers the full realm of an 
advanced object-oriented language and environment: 
single and multiple inheritance, dynamic binding, static 
typing, genericity and more within a simple, easy-to-leam 
language. 

Eiffel is the only environment which includes reliable 
software construction techniques: assertions, invariants, 
rigorous exception handling. Well defined interfaces for 
your existing software. Robust libraries of reusable 
components including X-based graphics. A powerful 
CASE environment ensuring automatic recompilation, 
computer-aided documentation, graphical browsing of 
system structures. Portability on all UNIX systems among 
others. Cross-development via the generation of self- 
contained C packages. Easy interface with packages and 


software written in other languages. And incredible 
support. 

Don’t worry, you won’t be alone. The list of major 
companies using Eiffel is impressive: Boeing, Philips 
GTE, British Telecom, Thomson, HP, Sun Microsystems, 
Cognos, Lawrence Livermore, Tektronix, Sandia, Telecom 
Australia, BNR, EDF, and on and on. 

Eiffel can solve your problems both today and 
tomorrow. Need more information? Just give us a call. So 
what are you waiting for? 

THE BOOK 

Object-Oriented Software Construction, Bertrand Meyer, called a 
"tour de force" by IEEE Software. Order from Prentice-Hall (ISBN 
013-629049-3), or directly from Interactive. 

THE SEMINAR 

Object-Oriented Design and Programming: created and 
presented by the designers of Eiffel. For information and 
registration, call us. 

SEE EIFFEL 

at all the major shows. Cal) for location and dates. 


Interactive 

Software Engineering Inc. 

270 Storke Road, Suite 7, Goleta, CA 93117 USA 
Telephone: (805)685-1006 FAX: (805)685-6869 

European Distributors: S.O.L., 4, rue Rene Barthelemy, 92120 Montrouge France Tel. (33) 1 46 5713 36, FAX (33) 1 46 57 01 03; 
ETNOTEAM, Via Staro 4,20134 Milano, Italy Tel. (39) 2 2141521, FAX (39) 2 2142231 


Eiffel is a trademark of Interactive Software Engineering Inc. 
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Honeywell-Bull, Waltham MA 
Honeywell-Bull used Design/OA to 
create a graphical micro-computer 
interface to monitor their nightly 
mainframe batch processing. The 
application retrieves batch process¬ 
ing data, initiates the batch jobs, 
and provides the operator real¬ 
time processing status throughout 
the night. 


PRC. McLean VA 
Planning Research Corporation 
used Design/OA to develop an Ada 
diagramming tool by adding Ada 
specific graphics to Design/2.0. 
This new tool, called AdaDesign, 
is used by Ada programmers for 
flow charting and system design. 


MIT, Cambridge, MA 
"With Design/OA we can go from 
an idea to an implementation very 
quickly. It has expanded the range 
of questions we can explore, given 
the same resources." 

Alexander Levis, Senior Research 
Scientist, Laboratory for Informa¬ 
tion and Decision Systems. 


AT&T Bell Labs, Middletown NJ 
AT&T Information Systems used 
Design/OA to build a reverse engi¬ 
neering application that provides 
dynamic documentation of large 
mainframe C programs. Program¬ 
mers can graphically view the pro¬ 
gram’s functions, files, variables, 
and their relationships. 


Design/OA,™ the Open Architecture Development System from Meta 
Software, is a development tool to create graphics-based applica¬ 
tions in a fraction of the time it would take with any other method. 

Graphics with Flexibility 

Use Design/OA to build a graphical environment for CASE, object- 
oriented programming, CAD/CAE, CIM or simulation applications. Or 
create a graphical front-end to your database, communications net¬ 
work, code generator or data processing system. 

Design/OA's extensible framework supports any user-defined 
methodology and graphical objects or icons, and provides connected 
graph logic, object and diagram hierarchies, integrated text process¬ 
ing and hypertext. 

Design/OA is the only development tool specifically created for 
building graphical system modeling applications. It provides a high- 
level programming interface to its C library routines and data struc¬ 
tures, and adapts to any programming style. The bottom line is a 
prototype in weeks and a finished application in months, not years. 

Cross-Platform Applications 

Whether your hardware environment is single or multi-vendor, 
Design/OA provides a common application programming interface 
forMS-DOS®/MS-Windows,™ UNIX™/X Window System,™ Apple 
Macintosh™ OS, and OS/2™ Presentation Manager™ (1990). 

Save Money 

Design/OA gives you a win/win solution. Not only does your applica¬ 


tion look and act exactly as you want it to, your cost per copy is less 
than the average cost for packaged, "off-the-shelf" applications. 

Eliminate Development Risk 

And if you want, Meta will assume your development risk. Our expe¬ 
rienced contract developers can build the application you want, the 
way you want it, on time and at a fixed price. 

So, join developers worldwide. Find out how Design/OA can give you 
the application you want with the time and cost savings you didn't 
think possible. 

Write, call or fax: Andrew Levin, Meta Software Corporation, 

150 CambridgePark Drive, Cambridge, MA 02140,800-227-4106, 
617-576-6920 (in MA), 617-576-0519 (fax). 



Meta Software 


© 1989 Meta Software Corp. Design/OA is a trademark of Meta Software Corp. MS- 
DOS is a registered trademark and MS-Windows is a trademark of Microsoft Corpo¬ 
ration. Macintosh is a trademark of Apple Computer, Inc. UNIX is a trademark 
of AT&T X Window System is a trademark of MIT OS/2 and Presentation Manager 
are trademarks of IBM. 
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VISUALIZATION IN COMPUTING 


Influence of Visual 
Technology on the 
Evolution of Language 
Environments 


Allen L. Ambler and Margaret M. Burnett 
University of Kansas 


W ith the availability of graphic 
workstations has come the in¬ 
creasing influence of visual 
technology on language environments. In 
this article we trace an evolution that began 
with the relatively straightforward transla¬ 
tion of textual techniques into correspond¬ 
ing visual techniques and has progressed to 
uses of visual techniques that have no natu¬ 
ral parallel using purely textual techniques. 
In short, the availability of visual technol¬ 
ogy is leading to the development of new 
approaches that are inherently visual. 


Terminology. In the seventies, much of 
the research on software development tech¬ 
nology concentrated on the development of 
loosely integrated tools for supporting vari¬ 
ous phases of the software development and 
maintenance process. The Unix develop¬ 
ment environment is an example of such a 
software support environment. 

Subsets of software support environ¬ 
ments directly relate to the programming 
process of a single programmer. These 
subsets, or programming environments, 
distinguish facilities for designing, coding, 
editing, documenting, and debugging indi- 


Since the advent of 
language environments, 
use of visual technology 
has evolved from 
visualization of existing 
textual approaches to 
inherently visual new 
approaches. We survey 
this evolution here. 


vidual programming tasks from facilities 
required for planning, tracking, and man¬ 
aging entire software projects. Program¬ 
ming environments may encourage par¬ 
ticular programming methodologies and 
particular languages. Some, referred to as 


language environments, are tightly inte¬ 
grated around a single language. Such 
tightly integrated, language-specific envi¬ 
ronments are the focus of this article. 

One of the first language environments 
was Interlisp. 1 Developed in the early 
seventies, Interlisp provided the basic 
functionality we associate with a language 
environment: a fully integrated, language- 
specific environment with its own user 
interface, editor, interpreter, and symbolic 
debugger. More recent language environ¬ 
ments have adopted and further refined 
many of Interlisp’s features. In some cases, 
Interlisp’s original ideas still represent the 
state of the art. 

At the time language environments were 
first developed, computer technology was 
in a more primitive state. Bit-mapped 
graphics and even CRTs were less com¬ 
mon than the standard Teletype terminal. 
In such an environment, the “friendliest” 
user interface was the briefest user inter¬ 
face. Therefore, language environments 
for many years were strictly command- 
driven. But the advent of visual technology 
brought dramatic changes in language 
environment user interfaces. 
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Layout and operation 
of the Smalltalk user 
interface 

The Smalltalk environment assumes a 
high-resolution bitmap display, a key¬ 
board, and a mouse with three buttons. 
The three mouse buttons are indicated by 
the appendage to the screen labelled (10, 
11, 12). 

We should note here that, in Smalltalk 
terminology, a window is a virtual screen 
large enough to contain an entire object. 
To accommodate physical screens, a 
window is viewed through a potentially 
smaller rectangular area that can be 
moved about on the surface of the win¬ 
dow. Only this rectangular area, called a 
view, is actually displayed on the physical 
screen. By moving the view (a process 
called scrolling), you can view any portion 
of the window. In common usage, this 
distinction between a window and a view 
into it is often lost, with the term window 


used to refer to the physical window 
rather than the virtual window. We use 
“window” to refer to the physical window. 
The System Browser window, identified 


by the tab (1), consists of the body (8) of 
a method “StoreElementsFrom:to:on:” (5) 
of object “AsYetUnclassified” (4) of object 
“ArrayedCollection" (3) of object “Collec- 


Visual user interfaces 

Multiple windows. Smalltalk 2 intro¬ 
duced not only a new language extending 
the object-oriented approach of Simula 67, 
but also a new and highly visual user inter¬ 
face. Alan Ka y pioneered the research 
leading to Smalltalk-76’s programming 
environmentTTtFcievTSed'a user-interface 
parad igm he called overlapping windows. 
Kay’s paradigm allowed for arbitrarily 
large virtual windows with modeless 
switching between windows and therefore 
between functions. (An interface with 
modes interprets commands with differing 
results depending upon the current mode. 
Typically, getting from one mode to an¬ 
other requires some definitive action, such 
as entering a key sequence.) 

The fundamental aspects of Kay’s para¬ 
digm were 

• displays associated with several user 
tasks could be viewed simultaneously; 

• switching between tasks would be 
done with the press of a button; 

• no information would be lost in the 
process of switching; and 

• screen space would be used econo¬ 
mically. 

The paradigm would serve as the basis for 
what Kay called an “integrated ejiyiron- 
ment,” in which the distinction between 


10 


thejtperating system and an applicatio n 
^WQuld^de^untTrevery^apabdity^Fany 
piece of software would apply to any piece 
of information. His paradigm contains the 
foundations for current user-interface 
paradigms not only for language environ¬ 
ments, but also for system shells, including 
that of the now familiar Apple Macintosh. 

See the sidebar on Smalltalk for a de¬ 
tailed example of the Smalltalk user inter¬ 
face. 

An alternative windowing paradi gm 
wasmtroduced in Cedar, 3 a language syn¬ 
thesizing" many’oTTFTe same language envi¬ 
ronment concepts to produce jin env iron¬ 
m ent for an Algol-fam ily language. This 
tiling paradigm is functionally similar to 
that of Smalltalk, differing primarily in 
detail and philosophy. See the sidebar on 
the sample Cedar screen for a description. 

Multiple views. With Smalltalk came 
the concept of multiple windows; with Pe¬ 
can 4 ca me the concept of multiple view s. 
The distinction is that multiple views share 
a common internal data representation of 
the same data. Whenever any aspect of that 
data changes, then all views change simul¬ 
taneously to reflect that change. The idea is 
that by representing data simultaneously in 
several ways, an individual user can 
choose those views that are most useful at 
a particular time. 

In Pecan an internal abstract syntax tree 
supports concurrent views. The user never 


views this internal abstract syntax tree 
directly, but its information is available 
through various views. For example, the 
editor provides a program listing view; the 
declaration editor provides a separate view 
of the program’s declarations; and the 
structured flow graph view provides a view 
of the program as a structured flow graph. 
Whenever any modification is made to the 
abstract syntax tree, via any view, all ac¬ 
tive views are notified of the change. The 
incremental compiler is treated as an un¬ 
displayed view; it receives notifications of 
any updates and recompiles the appropri¬ 
ate part of the code. The same approach is 
taken with the execution environment. The 
sidebar on Pecan shows several sample 
views. 

Sof tware th r ough Pictur es 5 is another 
graphically oriented language environ¬ 
ment with a family of graphic editors and a 
centralized database for information about 
the system under development. Each edi¬ 
tor supports a particular methodology of 
design or analysis developed in recent 
years. The major editors in Software 
through Pictures are the Dataflow Diagram 
Editor, which supports structured system s 
analysis; the Entity-Relationship Editor, 
'which suppdrfs the entity^relationshipdata 
modeling approach; the Transition Dia¬ 
gram Editor, which supports the user soft¬ 
ware engineering (USE) methodolog y; the 
Data Structure EdrtoirWfiTchsupports data 
structure definition; and the Structure 
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tions-Abstract” (2). The bold-lined boxes 
in each case indicate the selected item. 

To select a different item within the class 
hierarchy, you would use the pointer (9) to 
point to the new selection and click the left 
button (10). Given the hierarchical order¬ 
ing (from left to right), selecting a new 
item in any of panes (2, 3, 4) deselects 
the selections for all panes to the right of 
the new selection. You can scroll each se¬ 
lection pane should there be too many en¬ 
tries to fit. 

Whenever the pointer (9) is within the 
System Browser window and within one of 
the five panes (2, 3, 4, 5, 8), a scroll box 
(6) appears along the left side of the con¬ 
taining pane. The scroll box lets you scroll 
the text of the corresponding pane by 
moving the pointer into the scroll box and 
either grabbing and dragging the gray 
slider up or down within the scroll box to 
indicate the relative position desired within 
the corresponding pane or by moving the 
pointer within the scroll box slightly to the 
left or right of the slider and clicking it to 


move down (left of the slider) or up (right 
of the slider) one pane of information. 

The caret marker (7) indicates the cur¬ 
rent position within the text where, if you 
typed, characters would be inserted. You 
can move this marker arbitrarily by point¬ 
ing and clicking with the left button. In ad¬ 
dition, you can select sections of text by 
pointing at one end of a desired selec¬ 
tion, depressing and holding the left but¬ 
ton while moving the pointer to the other 
end, and releasing the left button. While 
you make the selection and until you de¬ 
select it (by the next click of the left but¬ 
ton), the selected text appears in reverse 
video. You can copy or delete selected 
text by choosing copy or cut from a pop¬ 
up menu associated with the center but¬ 
ton (11). You can subsequently paste (in¬ 
sert) it by moving the pointer to a new lo¬ 
cation and choosing paste from the same 
pop-up menu. 

A pop-up menu appears whenever you 
depress the center or right buttons. It 
contains a vertical list of possible opera¬ 


tions applicable in the current context. 

You select an operation by using the 
pointer and clicking the left button when 
the appropriate operation appears in re¬ 
verse video. After you select an opera¬ 
tion, the pop-up menu disappears. The 
list of possible operations associated with 
a pop-up menu changes from one pane 
to another, making the choice of opera¬ 
tions sensitive to context. 

The right button (12) can also be used 
for pop-up menus. The convention in 
Smalltalk is that the center button invokes 
operations appropriate to the current 
pane, while the right button invokes com¬ 
mands relating to the window in relation¬ 
ship to all other windows. Typical right- 
button commands allow closing, refram¬ 
ing (changing a frame’s size, shape, and 
screen position), or overlaying windows. 
As you can see in the figure, more than 
one window can be open at any time, 
with the active window indicated by hav¬ 
ing its tab (1) distinguished (by a reverse 
video title). 
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Sample Cedar screen 

In Cedar, windowing features, although 
similar to those in Smalltalk, are enhanced 
and have several added features, includ¬ 
ing icons and buttons. A physical w indow 
is called a viewer, and viewers ar e tiled, 
rather than overlapped as in Smalltalk. Til¬ 
ing ITITmetfiod of placmg~vtewers adja¬ 
cent to one another to cover the entire 
screen without covering any viewer, par¬ 
tially or totally, with any other viewer. 

Tiling versus overlapping has generated 
considerable discussion. With tiled view¬ 
ers the system automatically handles siz¬ 
ing and placement of the viewers, but the 
viewers are therefore not likely to conform 
to their contents in a way that maximizes 
the visibility of those contents. With ove r- 
lap ping wewera^ he opp osite is true: you 
—inijsni andie^ izing~and^pt5 eertierilm anu- 
afTyr'TFiisliliowryouTolTTal^ each viewer 
'"'conform to its contents. 

An open viewer occupies screen space. 
When a viewer is closed, it yields its 
screen space and appears only as an icon 
found at the bottom of the screen. When 
you reopen the iconic representation of a 
viewer by selecting and clicking its icon, 
the viewer is reallocated space on the 
screen. While ajaewer is closed, it is sus- 
peBded^SuLn oTtem^t ea. Hesizlng a 
viewer has theefTecToTresizing at least 
one other viewer unless it was the only 
viewer, in which case it cannot be resized. 

Within a viewer, other special viewers 
are possible. In particular, buttons are a 


special group of viewers used only for in¬ 
voking procedures. Buttons are repre¬ 
sented as text, possibly surrounded by a 
small box, or as icons. Selecting a button 
has the effect of invoking a procedure. 
This procedure typically performs some 
action on the associated viewer. Often 
buttons are arranged in menus and dis¬ 
played just below the caption bar, but 
they may be placed arbitrarily within an¬ 
other viewer. 

Unique to Cedar is a guarded button, 
displayed as a single line drawn through 
the normal button representation. It indi¬ 
cates a command with a potentially de¬ 
structive effect. To invoke a guarded but¬ 


ton, you must click it twice within a short 
time interval. 

The Cedar interpreter viewer shown 
here shows an instance in which the 
DWIM (Do What I Mean) facility has cor¬ 
rected a command error (1). This screen 
also has the performance measurement 
tool active (2) and shows the on-line 
documentation (3). In the documentation 
viewer, the buttons Reset and Save are 
examples of the guarded button feature. 

We adapted this figure from informa¬ 
tion provided in W. Teitelman’s “A Tour 
Through Cedar,” published in the April 
1984 issue of IEEE Software. 


October 1989 


































Sample views 
in Pecan 

The slack view (1) shows the values 
of the variables defined at the current 
point of execution. The two variables x 
and y are part of the INITIAL block, 
which includes the function gcd. The 
symbol table view (2) illustrates the 
scope of each symbol, including x, y, 
and gcd, as well as gcd’s formal 
parameters a and b. The editor view (3) 
shows the section of code currently 
being executed, namely the if b= 0 state¬ 
ment within the gcd function. The inter¬ 
preter view (4) displays the execution 
status and user inputs and outputs. The 
bottom portion of the interpreter view 
contains the ruler bar and several com¬ 
mand selections (Go, Break, Step, etc.) 
that allow you to control the speed and 
manner of execution. The flow diagram 
view (5) shows the diagrammatic ver¬ 
sion of the section of code currently 
being executed (the gcd function), with 



the current statement (if b=0) high¬ 
lighted. 

We adapted this figure from Reiss’ ar¬ 


ticle, “Graphical Program Development 
with Pecan Program Development Sys¬ 
tems,” published in the May 1984 issue 
of ACM SIGPIan Notices. 


Chart Editor, which supports structured 
design. Each editor can automatically add 
information to the centralized database as 
it is generated and modified. 

1 Beyond the visualization of textual 
languages. From experience with Pecan 
and generating systems to provide graphi¬ 
cal views of otherwise textual languages, 
Reiss observed that usejs_®erejimil£dby 
the jfl herent _o ne-dimensionalitv associ¬ 
ated with the underlying textual lan¬ 
guages. 6 He concluded that eff e ct ive -u s qaf 
the two-dim ensional capabilities of gra- 

rg'uages'whoseTnatural expression was gra¬ 
phical, not textual. Reiss responded by 
developing the Garden^sJstenTto^iccept 
descrlptrons-erfMsuaTas well as textual 
programming objects. Others, making this 
same observation, have worked on new ap¬ 
proaches to visual languages (see “Visual 
languages” below). 

Like Pecan, Garden uses a common in¬ 
ternal representation model, in this case an 
o bject-oriented environ ment-complete 
< wTth inherita nce. New conceptual models 
are described~By defining new objects that 
represent the fundamental objects of the 
new conceptual model, then by defining 
the interpretation of manipulations to these 
new objects. Each of these new objects can 
be given a visual representation as well as 
a textual representation. The interpretation 


of visual manipulations can be described 
as well. To simplify the process, Garden 
provides an extensive library of database, 
process management, user-interface, dy¬ 
namic display, debugging, and editing 
facilities usable in defining and testing 
new conceptual models. 

See the sidebar on Garden for a descrip¬ 
tion of the process of defining a new con¬ 
ceptual model. 

Visual editing 

Syntax-directed editing. One of the 
more prevalent visual editing techniques 
to appear in language environments is 
syntax-directed editing. Here, the editor is 
aware of the language’s syntax and can 
thus either give the programmer immedi¬ 
ate feedback whenever a syntax error is 
typed in or prevent such errors completely 
by forcing the programmer to use a tem¬ 
plate based upon the language syntax. 

As with windowing systems above, 
whole papers discuss syntax-directed edi¬ 
tors in detail. We will just touch on a few of 
the more prominent features as they have 
appeared in language environments. The 
two syntax-directed editors discussed, the 
Cornell Program Synthesizer editor and 
the Aloe editor used in Gandalf, follow the 
philosophy that if a portion of the program 
is created based on some template, then the 


structure created by that template must be 
preserved during editing. This philosophy 
allows the use of visual hierarchical tra¬ 
versal techniques based on a program’s 
structure. The examples shown in the ac¬ 
companying sidebars on the Cornell Pro¬ 
gram Synthesizer and the Aloe editor illus¬ 
trate the visual techniques used in travers¬ 
ing and editing programs using the two 
editors. 

The Cornell Program Synthesizer 7 is a 
language environment for a subset of PL/1 
called PL/CS. PL/CS programs are con¬ 
structed through a syntax-directed editor 
that uses program-structure-based editing. 
Structural aspects of PL/CS programs, 
such as blocks and statements, are entered 
and edited through a special set of lan¬ 
guage-specific commands. These lan¬ 
guage-specific commands generate tem¬ 
plates that outline the language’s syntactic 
structure and provide a preformatted, prop¬ 
erly indented, parentheses-matched form 
with place-holders to be filled in by the 
programmer. Non-structure-based 
phrases, such as expressions, comments, 
and identifier lists, are entered using con¬ 
ventional text-based editing commands, 
which are only available for such nonstruc- 
tural phrases. 

The programmer is similarly restrained 
from modifying a statement. Text entered 
to replace a place-holder must continue to 
match the syntactic part specified by the 
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Defining a new 
conceptual model 
in Garden 

In Garden, a new conceptual model 
can be described in three steps. The 
type structure is specified, the seman¬ 
tics for each type is specified, and the 
syntax (textual and/or visual) is speci¬ 
fied. Three types are needed for the fi¬ 
nite state automaton in the figure: one 
describing a state, one describing a 
transition, and one describing the com¬ 
plete automaton. 

The type editor window (1) shows 
the type definition and visual syntax for 
a state. It has no Super Types (2), in¬ 
cludes the data fields id and accept 
(3), and includes the constant field Pic¬ 
ture (4), which maps a state to a basic 
visual object (5) used to display the id 
field. All fields of a data structure need 
not be displayed with the visual syn¬ 
tax. Also, a single data structure can 
have mappings to more than one vis¬ 
ual representation. 

In addition to basic visual objects, 
composition objects are available. For 
example, a layout object can be used 
to display more complex or variable 
data structures than simple fields or 
records. The complete automaton has 
been mapped to a layout object com¬ 
posed of the basic object representa¬ 
tion for states and several arc objects 
visually representing the transitions. 

After the types are defined, the pro¬ 
grammer defines their semantics (not 
shown in this figure) by writing func¬ 
tions using the textual Lisp-like lan¬ 
guage currently provided by Garden 
and other graphical or textual meta¬ 
phors that have already been defined. 

In (6), the programmer is experi¬ 


menting with an instance of the au¬ 
tomaton type (8). Using this editor, the 
programmer has created the states us¬ 
ing a series of selections, insert com¬ 
mands, and dialogue boxes. Similarly, 
the transitions have been created by 
selecting the from and to states, using 
the connect command, and filling in 
the values requested in the dialogue 
boxes. Finally, after several sample 


evaluations (not shown), the current 
state has become “S4" (7). 

We adapted this figure from Reiss' 
“Garden Tools: Support for Graphi¬ 
cal Programming,” published in Ad¬ 
vanced Programming Environments, 
Lecture Notes in Computer Science 
#244, from Springer-Verlag, New 
York. 


Syntax-directed editing using 
the Cornell Program Synthesizer 


In the Cornell Program Synthesizer, 
you enter language-specific commands 
as text, then depress a special function 
key. 

The editor command 


would produce the following template: 

IF ([Condition ) 

THEN statement 
ELSE statement 


where “condition” and “statement” are 
place-holders. The box around the 
letter “c,"0, shows the placement of 
the cursor; it denotes that “condition” 
is to be replaced by user-entered text. 
When the programmer enters text to 
replace “condition,” the synthesizer will 
check that the entered text is a 
Boolean phrase. Should the entered 
text not match the syntactic part desig¬ 
nated by the place-holder, the pro¬ 
grammer will be so advised. Similarly, 
the programmer replaces the two oc¬ 


currences of place-holder “statement” 
by further language-specific com¬ 
mands, introducing yet more templates. 

The use of language-specific com¬ 
mands to generate the more complex 
syntax of the language PL/CS and the 
syntactic checking of place-holder 
replacement text prevents the pro¬ 
grammer from entering syntactically 
incorrect programs. Further, some 
static semantic checking prevents 
errors such as referencing an 
undeclared identifier. 
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Syntax-directed 
editing using the 
Aloe editor 

The language-specific command “wh" 
might be used to cause the place-holder 


to be replaced by 

while l%cond I do 
%stmt 
od 

This template provides the structural 
parts of a while statement: the required 
syntactic tokens (while, do, and od) with 
proper indentation, and place-holders 
for a conditional expression (%cond) 
and the statement body (%stmt). The 
cursor is placed automatically at the 
first place-holder (%cond). The user 
may then type in an appropriate 
Boolean expression, replacing the 
%cond place-holder or, depending upon 
the abstract syntax, the user might in¬ 
voke another constructive command 


expanding and replacing %cond. For 
instance, replacing %cond with the tem¬ 
plate for an and expression yields 

while ( |%expr[ and %expr) do 
%stmt 
od 

The abstract syntax can be specified 
such that all expressions are composed 
entirely by using constructive com¬ 
mands or by entering a simple variable 
name or value. When specified in this 
way, editing, which is required to follow 
the parse tree, can become very rigid. 
For instance, to edit ((a + b) + c) to be 
(a + (b + c)) requires deleting the syn¬ 
tactic part (a + b) and replacing it with 
a, followed by replacing c with the syn¬ 
tactic part (%expr + %expr), and finally 
replacing the two occurrences of %expr 


by b and c. The alternative is an ab¬ 
stract syntax that stops short of gener¬ 
ating expressions, that is, there are no 
syntactic parts specified as replace¬ 
ments for the place-holder %expr. Thus, 
expressions would be typed and edited 
as single nodes of the parse tree. Ac¬ 
tion routines might still be used to check 
syntactic correctness. 

Up and down movement (cursor-pre¬ 
vious and cursor-next) corresponds to 
lateral movement within the parse tree. 
In and out movement (cursor-out and 
cursor-in) corresponds to vertical move¬ 
ment within the tree. For instance, in 
the code shown here, the structural part 
is shown on the left and the cursor posi¬ 
tion is identified by a box. If the cursor 
is initially positioned as (cursor), then 
up, down, in, or out causes cursor 
movement as shown. 


if sr en 

if eof(input) then if|eof(inputl]then if eof(input) then if eof(input) then 

| done := true; | done := true; done := true; [cjone := true; 

read(ch); read(ch); | read(ch); | read(ch); 

if eof(input) then 

Structural Part 

(cursor) (up) (down) (in) (out) 



Graphical 
representation 
in Use.It 

The binary tree depicts the decom¬ 
position of a process for making 
wooden stools. For each node, repre¬ 
sented by a box (1), the input objects 
are listed on the right of the box and 
the output objects are listed on the left 
side of the box. The join control struc¬ 
ture (2) decomposes MakeStool into 
two nodes, MakeParts and Assemble- 
Parts. Use of join requires that the 
right node execute before the left 
node. The right node has the same in¬ 
puts as its parent, but cannot produce 
any of the outputs of its parent, only 
intermediate values. The left node has 
as inputs only the intermediate values 
of the right node and must produce as 
outputs all of the outputs of the parent 
node. 

Next, the include control structure 
(4) is used to further decompose 
MakeParts into MakeLegs and Make- 
Top. Use of the include allows its 
subnodes to execute in any order or 


concurrently. The inputs and outputs of 
each node are disjoint, and the union of 
the inputs and outputs is exactly the 
inputs and outputs of the parent node. 

Finally, the or control structure (6) is 
used to decompose MakeLegs into 
Carve and Turn. Use of the or control 
structure requires that exactly one of 
the subnodes be executed depending 


upon the evaluation of a condition (5). 
Both nodes have all inputs of the par¬ 
ent node and produce all outputs of the 
parent node. 

We adapted this figure from J. 
Martin’s System Design from Provably 
Correct Constructs, published by Pren¬ 
tice Hall, Englewood Cliffs, N.J., 1985. 
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place-holder. A syntactic structure entered 
through language-specific commands 
must be edited as a structural unit through 
language-specific commands. The pro¬ 
grammer can clip, delete, and insert entire 
structural units. When a structural unit is 
clipped or deleted, it is replaced by its 
place-holder. Likewise, inserted structural 
units must replace corresponding syntactic 
parts; they will be reindented and re¬ 
checked for syntactic correctness. 

The syntactic structure affects cursor 
movement as well. When the cursor is 
moved, it will skip over all but text and 
structural units, permitting itself to be 
positioned only where modifications are 
allowed. 

A program can be run at any stage of 
development. Each structural unit is trans¬ 
formed into interpretable code as it is input 
and checked. Execution is thus immediate. 
Once begun, execution is suspended when 
the interpreter encounters either an error or 
an unexpanded place-holder. Upon detect¬ 
ing an error, the interpreter indicates the 
error and passes control back to the user, 
who then may correct the problem or re¬ 
start. Similarly, when the interpreter en¬ 
counters an unexpanded place-holder, it 
will stop, allow the user to insert the re¬ 
quired code, and then continue. 

The C ornell Pr ogram S ynthesizer also 
hasa visual tracing capability, a for efunne r 
of program animation. (Program anima- 
fionrefersTto theTprecess of displaying the 
operation of a program through visual 
representations that dynamically change 
as the program executes. Selected vari¬ 
ables or even entire data structures are 
displayed, usually graphically, with their 
contents changing dynamically as the pro¬ 
gram alters their values. For example, for a 
program that maintains a binary search tree 
of customers, the tree of customer names 
might be displayed graphically. Whenever 
a node is added or deleted, the display of 
the tree would be updated on the screen.) 

In the Cornell Program Synthesizer, a 
cursor follows the flow of control through 
the program during execution. In addition, 
the synthesizer provides additional win¬ 
dows for monitoring variables and display¬ 
ing results. The variable monitoring fea¬ 
ture dynamically displays variable values 
using a least-recently modified approach 
to displaying large numbers of variables in 
limited screen space. 

See the accompanying sidebar for an 
example of syntax-directed editing using 
the Cornell Program Synthesizer. 

The Gandalf system 8 uses an editor 
generated by Medina-Mora and Notkin’s 


Aloe editor -generator. Such an editor has a 
common kernel ot'editing commands that 
are language-independent and a set of 
constructive commands that are language- 
dependent. Editing commands are used for 
generic operations such as manipulating 
parse trees. Typical editing commands 
delete a construct or move the cursor. 
Constructive commands use abstract and 
concrete syntax descriptions to generate 
templates for each structural part. Cursor 
movement in building or editing a program 
parallels movement in the parse tree. In 
particular, the cursor is moved up, down, 
in, or out to the appropriate place-holder. 

See the accompanying sidebar for an 
example of syntax-directed editing using 
the Aloe editor. 


Specification-directed editing. The 

concept of structure-based editing can be 
extended further by imposing additional 
' rule's on iKe structure of programs and 
enforcing these rules through the editor. 
These rules can be used for purposes such 
as ensuring that only program s prova bly in 
accordance with aprescnbej fse t ofspec r 

cusses two graphically oriented language 
environments that use such structure- 
based editors. 

Higher Order Software’s Use.lt 9 takes a 
formaTgraphicany"oriehted approach to 
program construction. Use.It generates 
code, in a variety of languages, dire ctly 
from formal specifications, which are en- 
tered~3nd editecTus mg ~a structure-ba sed 
editor t hat enforces decomposition ba sed 
on prov ably correct design axioms that 
limTtThe interactions between mod ules. 

bina ry trees known as control m aps. Each 
riodeof thelree represents a function hav¬ 
ing a number of input and output objects. 
In a graphical representation, input objects 
are listed to the right of the node and output 
objects are listed to the left. Leaf nodes are 
t ypically irreduci blej ow-level prim itive 
functions. Non-leaf nodes are decomposed 
Into subfunctions using the control struc¬ 
tures join, include, and or, each of which is 
consistent with the six axi omsj m w hich 
the methodology relies. 

~~Tn UseTftr"tfttniecomposition of func¬ 
tions into primitive subfunctions is for¬ 
mally specified and rigidly enforced by the 
graphical editing process. The preciseness 
of this decomposition ensures the internal 
consistency of the code generated by 
Use.lt. In particular, Use.It ensures that 
any decomposition is logically consistent 
with the six basic axioms describing the 


structural interfaces between pieces of 
code. These axioms formally define a reli¬ 
able system for structured coding. 

See the accompanying sidebar for an 
example of graphical representation in 
Use.It. 

A similar graphical editing technique 
is employed by PegaSys, 10 a system that 
uses graphical images to formally repre¬ 
sent program design specifications. The 
emphasis in PegaSys is on the use of for¬ 
mal graphical specifications as docu¬ 
mentation and as a means to verify that 
(user-written) program code meets spec¬ 
ifications. 


manipulated graphically using editing 
techniques subject to system-imposed 
syntactic and semantic constraints. The 
constraints ensure that certain properties 
are preserved during the process of design¬ 
ing a program by successive refinement. 

This concept of a rigorously controlled 
decomposition based on a mathematical 
logic is similar to Use.lt, although the rules 
used and the properties preserved differ for 
each system. 

Once the graphically edited design 
specifications are complete, they are 
manually mapped onto the implementa¬ 
tion code, developed using PegaSys’s 
structure-oriented Ada editor. Finally, the 
system formally verifies that the program 
is consistent with its design specifications. 

The sidebar on PegaSys shows two 
levels in a formal dependency diagram 
hierarchy. 

From visual editing to visually trans¬ 
formed programming. Each of the above 
visual editing systems is to some degree 
template-oriented. That is, some portion of 
a program is identified for replacement, a 
desired replacement template is selected, 
and then the replacement is performed as 
specified by the template, possibly subject 
to certain rigorously controlled rules. 
Clearly, this template-oriented approach 
can be carried to such an extreme that the 
entire program is constructed by visual 
editing techniques alone. 

The earliest approaches to visual pro¬ 
gramming consisted of visual editors for 
traditional imperative textual languages. 
Often the control flow was given a picto¬ 
rial or diagrammatic representation, such 
as a flowchart or Nassi-Schneiderman 
diagram. Pecan included such views to 
represent Pascal programs. Later ap¬ 
proaches discarded the textual version 
completely, using the diagram version as 
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Formal dependency 
diagram hierarchy 
using PegaSys 

The accompanying figure shows two 
levels in a formal dependency diagram, 
or FDD, representing a networking 
scheme designed using PegaSys. In 
Level 2 of the figure, the processes 
Source (1), Destination, H2H_Sndr, 
H2H_Rcvr, and Data_Link_Protocol 
are all denoted by ellipses. Dataflow 
relations are denoted D on the labeled 
arcs msg (2) and h_pkt, which denote 
the types of data being passed. The 
active types msg and h_pkt are also 
listed at the bottom of the screen (4). 

Level 3 is a refinement of Level 2, 
developed by the user selecting the 
entity to be refined (5), then, using the 
appropriate menu commands (3), con¬ 
structing the replacement entity (6). 
Note that the dataflow relations D for 
this entity have also been refined into 
read relations, denoted R, and write re¬ 
lations, denoted W. 

To augment the FDD, PegaSys also 
includes a facility to associate text with 
any icon. 

We based this figure on Moriconi 
and Hare’s "PegaSys: A System for 
Graphical Explanation of Program De¬ 
signs," included in the July 1985 Pro¬ 
ceedings of the ACM SIGPIan 85 Sym¬ 
posium on Language Issues in Pro¬ 
gramming Environments. 



the only representation of the program and 
graphical editing of the diagram for con¬ 
struction and editing of the program. 

A good example of such a system, Piet/ 
D," uses a conventional imperative lan¬ 
guage paradigm that replaces all keywords 
with iconic representations. The resulting 
language creates and manipulates flow¬ 
charts with the added ability to create new 
icons to represent subcharts. Thus, the 
language semantics are conventional, pro¬ 
gramming requires conventional concepts 
and thought processes, and the resulting 
programs are of equivalent complexity to 
the corresponding textual programs. Piet/ 
D concentrates on using visual images to 
improve our ability to comprehend and 
edit programs. 

Reiss’s observation about editable 
views (see “Beyond the visualization of 
textual languages” above) applies to visual 
editing as well. Visual editing of an other¬ 
wise textual language can severely limit 
the power and usefulness of visual technol¬ 


ogy. Clearly, enforcing structural decom¬ 
position rules still has value, as in Use.lt 
and PegaSys. However, some of the early 
approaches to visual programming that 
used graphical technology merely to re¬ 
place corresponding typing have drawn the 
criticism that they do little more than force 
a programmer to use menus and other 
graphical techniques for operations that 
can often be typed textually faster. Unfor¬ 
tunately, this criticism has unjustifiably 
been extended to visual programming in 
general. 

Visual languages 

Visual programming uses visual, rather 
than textual, technology. The develop¬ 
ment of visual programming languages 
represents a further^Kp-4n-4h&-eveltrtrcfn 
toward more visual language environ¬ 
ments. Visual languages are generally 
subdivided into tjve^categories. The first 


category, visually transformed languages, 
includes those visual languages that are 
inherently nonvisual but have superim¬ 
posed visual representations. These are the 
visually edited traditional languages dis¬ 
cussed in the prior section. They empha¬ 
size facilitating our ability to specify and 
comprehend programs using existing lan¬ 
guage paradigms. 

The second category, naturally visual 
languages, attempts to develop new pro¬ 
gramming paradigms whose inherent natu¬ 
ral expression is visual and for which there 
may be no strictly textual equivalent. In 
this section, we survey several divergent 
naturally visual languages and language 
environments. 

By the very nature of the concept of 
visual programming, it is often difficult to 
separate a visual language from its lan¬ 
guage environment. It is this high degree of 
integration between the language and its 
environment that makes naturally visual 
language technology such an influential 
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A Celsius-to-Fahrenheit temperature 
converter constructed in ThingLab 


Inserting several instances of previ¬ 
ously defined classes into the window 
(Constant (2), Times (3), and Plus) and 
entering the constants' values of 1.8 
and 32.0 creates the prototype of the 
TempConverter (4). Connecting two in¬ 
stances of NumberPrinters (1,5) to dis¬ 
play the Celsius and Fahrenheit tem¬ 
peratures results in the PrintingCon- 
verter as shown in the figure. It works 
because the constraints placed on Plus 
and Times force adjustment of one of 
the Celsius or Fahrenheit temperatures. 
Whenever the Celsius temperature (1) 
is edited, the Fahrenheit temperature 
(5) will be adjusted. Also, because of 
the multi-way nature of the constraints, 
editing of the Fahrenheit temperature 
will result in adjustment of the Celsius 
temperature. 

We based this figure on Borning’s 
“The Programming Language Aspects 
of ThingLab,” published in the October 
1981 issue of ACM Transactions on 
Programming Languages and Systems. 



area in language environment research. 

Dataflow paradigm. Visual languages 
based on the dataflow paradigm might be 
considered visually transformed lan¬ 
guages. However, it can be argued that the 
dataflow paradigm is based on dataflow 
diagrams, in which a program is composed 
of functional modules, with connecting 
paths between inputs and outputs. In tex¬ 
tual languages based upon this paradigm, 
dataflow diagrams are normally drawn 
first as part of the program design process 
and then translated into textual syntax. 
Visual languages based on this paradigm 
simply omit the translation to text. 

Constraint-based paradigms. Many 
constraint-based programming languages 
are well suited to a visual representation. 
The advantage of a visual representation 
for this paradigm lies in the multi-way 
nature of constraints. A constraint may 
affect many variables, which in turn may 
affect many more; such complicated inter¬ 
relationships are often easier to see in a 
diagrammatic representation than in a tex¬ 
tual representation. 

ThingLab 12 is an experiment in con¬ 
straint-based programming. Given a set of 
constraints (rules) describing the invariant 
properties and relationships of all objects 


in a particular problem space, then the set 
of solutions is the set of values that simul¬ 
taneously satisfy all constraints. With suf¬ 
ficient constraints, the set of solutions can 
be made arbitrarily small, thus effecting a 
solution. 

This approach in many respects re¬ 
sembles logic programming, where con¬ 
straints are analogous to rules and relations 
and finding a set of values that satisfies all 
given constraints is analogous to resolving 
a query. ThingLab is a constraint-oriented 
simulation language environment that 
supports the construction of simulation 
environments using constraints and con¬ 
straint-inheritance mechanisms. It incor¬ 
porates inheritance (from the object-ori¬ 
ented paradigm of its underlying implem¬ 
entation language) and allows inheritance 
of the constraints themselves. This ap¬ 
proach has the disadvantage that the inher¬ 
ited constraints may conflict when mul¬ 
tiple inheritance is allowed. Still, many 
recent constraint languages incorporate 
various forms of inheritance. 

Based on Smalltalk and heavily influ¬ 
enced by Sutherland’s SketchPad, an early 
constraint-based graphical communica¬ 
tion system that allows the user to directly 
draw and edit pictures on the screen using 
a light pen, ThingLab incorporates ele¬ 
ments of graphical programming-by-dem- 


onstration. Its influence shows in later 
VisuaHanguage environments, most nota¬ 
bly ThinkPad and Rehearsal World, both 
described below. 

See the sidebar for an example of a 
Celsius-to-Fahrenheit temperature con¬ 
verter constructed in ThingLab. 

Programming-by-demonstration. 

This is a naturally visual process for which 
there is no textual equivalent. Program¬ 
ming is done by graphically manipulating 
the data on the screen, demonstrating to the 
computer what the program should do. The 
advantage to this approach is obvious — it 
is easier for a programmer to perform a 
process than to describe textually how to 
perform the process. 

ThinkPad is a declarative, graphical, 
prggramhrifig^By^HeiTnmsTrattorr language 
and environmentT 5 To'pefft5fm _ program- 
f ming^By=detfionstration, the user graphi¬ 
cally manipulates a diagrammatic repre¬ 
sentation of a data structure to demonstrate 
the operations on the data. An automatic 
mapping of the user’s manipulations to 
Prolog code implements the program. 

In ThinkPad, the user defines a data 
structure by drawing its graphical proper¬ 
ties. In fact, a single data type can have 
multiple diagrammatic representations 
(“forms”), all specified graphically. The 
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Defining an operation 
in ThinkPad 

A simple example will illustrate the 
use of ThinkPad. The problem is the in¬ 
sertion of nodes into a binary tree. The 
first step (not shown) is to define a bi¬ 
nary tree, using ThinkPad's data editor. 
This is done by selecting a shape from 
the Shapes menu to represent a node 
(in this example, a rectangle) and re¬ 
sizing and repositioning it to suit. The 
fields within the node are similarly 
selected, resized, and repositioned. 

The user began by naming the opera¬ 
tion INSERT and specifying the type of 
all parameters and results (1). The sys¬ 
tem knows from the parameters that two 
graphical forms, an integer and a tree 
node, will be needed for the operation, 
which it automatically displays (3,4). 

Next, the function is described by 
identifying a series of cases and for 
each case demonstrating the corre¬ 
sponding operation. Each case is distin¬ 
guished by a unique condition (11). In 
this case the condition, int 0 < node 1 -> 
val (10), is entered by sequentially se¬ 
lecting int 0 (3), the less-than symbol 
(12), and val of node 1 (5). 

The user now specifies the results (7) 
of the INSERT operation by manipulat¬ 
ing the forms on the screen to demon¬ 
strate the operation for this case. First, 
the tree node is copied, by depressing 
the copy button (9) and then selecting 


node 1 (4) to create a new node (8). 

Next, the function button (6) is 
pressed and INSERT is selected (15) to 
indicate a function recursive call. Then, 
the arguments are indicated by copying 
int 0 (13) and expanding (9) I (16) of the 
copy of node 1 (8), giving the structure 
of the left node (14). 

The user has now completely defined 


operation INSERT for one case and can 
continue in the same way for each re¬ 
maining case (2). 

We adapted this figure from 
“ThinkPad: A Graphical System for Pro¬ 
gramming by Demonstration," by Rubin, 
Golin, and Reiss in the March 1985 is¬ 
sue of IEEE Software. 


multiple forms capability allows ThinkPad 
to support multiple views of a single data 
type. The user can define operations on the 
data structure by manipulating the repre¬ 
sentation on the screen. In addition, the 
user may specify type constraints that the 
operations must preserve. Pointing and 
clicking selects the desired conditions, 
provided by the condition editor. 

I nternally, the da ta structure is repre- 

I sente d bv a set ofP 'rolog assertions about 
th£"aata. Relationships in the data structure 
rfre~aTso~mapped into Prolog assertions, 
and type constraints are implemented as 
predicates. All the assertions pertaining to 
one data structure are grouped into a sepa¬ 
rate set of Prolog clauses. Graphical speci¬ 
fications are stored in another library, with 
cross links to the set of Prolog assertions. 

Because ThinkPad internally defines 
operations as transformations from one 
arrangement of the data structure to an¬ 
other, manipulat ing the data structures 
grap hically is the^quiy afent-oLpregram- 
mfhgTTlowever, while~tHsre is alfirect 


mapping from the graphical manipulation 
of the data structures to a program (in this 
case implemented in Prolog), there is no 
mapping from the program to the graphical 
representation of the data structures. Exe¬ 
cution and debugging revert to the text- 
based Prolog code, rather than to the visual 
interface that exists during the creation of 
the code. 

See the accompanying sidebar for an 
example of defining an operation in 
ThinkPad. 

Rehearsal World, 14 a visual program- 

ifrTng~langn>ge environment dpvkpd_frir 
non pr ogramm ers, is one of the earliest 
(Stvlronments to fully support visual pro¬ 
gramming. Rehearsal World uses a theater 
metaphor. The basic components, called 
performers, interact with each other on a 
stage (the screen) by sending cues. The 
screen is the stage upon which performers 
(objects) perform the actions the user has 
taught them for a particular production 
(program). 

Rehearsal World includes several pre¬ 


defined primitive performers, each of 
which understands a large predefined set 
of cues. Any existing performer can be 
copied; thus, each performer acts as a 
prototype from which other performers can 
be generated. The use of predefined per¬ 
formers and cues is, in essence, the integra¬ 
tion of predefined code segments into the 
language environment itself. 

The actual code generated by Rehearsal 
World is Smalltalk, but the programming 
process normally occurs strictly through 
graphical or visually oriented manipula¬ 
tion; hence, the user does not have to 
know Smalltalk to program in Rehearsal 
World. Likewise, code is normally de¬ 
bugged visually, by observing the perform¬ 
ers’ behavior during rehearsals, although 
additional lower-level debugging facili¬ 
ties are available. 

For a closer look, see the sidebar “The 
Rehearsal World theater.” 

In PT, or Pictorial Transformations, 15 
programming takes the form of first de¬ 
scribing visual data representations, then 
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The Rehearsal World 
theater 

The user starts by selecting from the 
menus of available stages (1) and 
troupes (2). Each troupe contains a set 
of performers represented as icons. For 
example, the BasicTroupe consists of a 
Text performer (3), a Counter performer 
(4), and a Number performer (5). For 
each performer, a category menu (7) is 
available as a pop-up display via a 
mouse button. This category menu con¬ 
tains certain commonly used cues (in 
lowercase) and categories of other cues 
(in uppercase). Most categories are 
common to all performers; a few (in 
bold) are unique to an individual per¬ 
former. Selecting a category gets a cue 
sheet (6), which lists the cues available 
and related to the selected category. 

The user can audition a performer by 
selecting a cue and observing its action. 
For example, a Text performer offers a 
variety of functions associated with a 
text editor. The Text performer performs 
these various operations when sent ap¬ 
propriate cues (by the user or another 
performer). For example, setText ‘good ¬ 
bye' will cause ‘goodbye’ to be dis¬ 
played by the Text performer. 

A performer learns by demonstration 
to send another performer a particular 
cue. The user initiates this by sending a 
performer a cue indicating that an ac¬ 


tion is to be defined and telling the sys¬ 
tem to “watch” the demonstration. A tiny 
“eye” icon, such as the one in window 
(6), opens to indicate the system is 
watching. The user then demonstrates 
the cues to be sent to other performers 


by simply selecting those cues from their 
cue sheets. 

We based this figure on Finzer and 
Gould’s “Programming by Rehearsal," in 
the June 1984 issue of Byte. 


graphically manipulating them to develop 
program algorithms. Objects in PT, also 
called dynamic icons , consist of tuples of 
attribute-value pairs (much like associa¬ 
tion lists in Lisp) and an iconic display 
function that creates an object’s display 
image as a function of its attribute-value 
pairs. For instance, its attributes may de¬ 
termine whether or not an object is shaded, 
where it is located, or how big it is. The 
value of an attribute may be another object, 
and thus objects can be hierarchically 
structured. A graphical object editor al¬ 
lows construction of new object types. 

A procedural language, PT uses a film- 
making metaphor. Programming requires 
designing graphical objects and using such 
objects to demonstrate the workings of 
algorithms. A picture is a collection of 
graphical objects; a film (analogous to a 
procedure or program) is a sequence of 
manipulations performed on a picture. A 
programmer first selects a starting picture, 
then works through pictorial transforma¬ 
tions on that picture. The process is re¬ 


corded as one or more films. 

By collecting object icons into a picture 
and filming a sequence of manipulations 
on objects of this picture, the programmer 
obtains a visual representation of a pro¬ 
gram’s execution that results from defin¬ 
ing the program itself. Thus, the way the 
programmer selects and modifies objects, 
plus the dynamic representation of an ob¬ 
ject based on its attribute values, aids the 
programmer in designing a program’s ani¬ 
mation simultaneously with its algorithms. 

See the sidebar “Filming in PT.” 

Form-based paradigms. You can think 
of form-based programming as a generali¬ 
zation of spreadsheet programming. Even 
though it uses text, in a spreadsheet the 
relationships between the data and the 
expression of the computations are repre¬ 
sented as part of the form itself, not de¬ 
scribed textually. Hence, the spreadsheet 
is naturally visual. It would be hard to 
imagine a purely textual version of a 
spreadsheet as natural to use, partly be¬ 


cause the visual and interactive aspects of 
spreadsheets play an important role in al¬ 
lowing nonprocedural programming. 

The visual representation of a cell ma¬ 
trix allows the omission of the concepts of 
variables, declarations, and output format¬ 
ting. In addition, it contributes to the visual 
image of a large cell matrix wherein each 
value is normally computed just once per 
evaluation, with the order of evaluation 
derived, not specified. The visual interface 
with its various operational areas allows a 
modeless operation. Hence, being visual 
contributes significantly to the success of 
spreadsheet languages. 

Forms 1 6 extends the spreadsheet para- 
digm over a larger problem donjain. It 
"relies on a visual representation general¬ 
ized from the spreadsheet representation to 
minimize required language concepts. The 
basic “sheet” in Forms is a form, corre¬ 
sponding to a piece of paper on which you 
can place cell matrices, called objects. A 
cell expression can reference any cell (or 
cells) in any object within the containing 
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form or within other forms, subject only to 
the restriction that the resulting derived 
evaluation must not be made to be circular. 

Cell matrices are bounded or un¬ 
bounded. A bounded cell matrix is one of 
fixed, known dimensions, whereas an 
unbounded cell matrix has at least one 
dimension that is unknown during the 
specification of the form. However, all 
objects must have their dimensions fixed 


prior to evaluation. Values for unbounded 
objects are specified by generic cell speci¬ 
fications stated in terms of the yth cell, 
combined with specific cell specifications 
for specific fixed cells. A subform is simi¬ 
lar in content to a form, but certain objects 
will inherit their values as parameters. 
These objects map onto other objects dur¬ 
ing evaluation. In addition, the value of 
one or more objects may be returned. 


Forms is a declarative language, in that 
there is no concept of “state.” For each 
evaluation of a form or subform, each cell 
is evaluated only once. Cyclic evaluation 
is not allowed. However, iteration and 
recursion can be accomplished via re¬ 
peated invocations of a subform, each 
creating a new instance of the subform. 
Hence, the set of all forms and subforms 
used for a given computation provides a 


Filming in PT 

(Pictorial 

Transformations) 



The screen here shows the Pictorial 
Transformations programming environ¬ 
ment during the process of program¬ 
ming a solution to the stable marriage 
problem. (This problem attempts to 
match men and women in marriage 
based on their stated preferences for 
each other.) In PT, an object is a tuple 
of attribute-value pairs together with an 
iconic display function that describes 
how to display an object based on its 
attribute-value pairs. 

The collection of objects available for 
use in constructing new objects is dis¬ 
played in the window at the upper left 
(1). In this example, several structured 
objects have already been built. The 
6x5 matrix in the center window (2) is 
a construction of a column of objects, 
each a row of objects, each a text ob¬ 
ject. The attribute-value tuple associ¬ 
ated with the selected subobject at 
(3) is displayed in the Attributes win¬ 
dow (6). 

In this example, an oval shape indi¬ 
cates a female, and a thin contour indi¬ 
cates unmarried. In PT, attributes like 
contour and shape not only convey in¬ 
formation about the visual representa¬ 
tion of the algorithm, but also can be 
tested and used directly in the program 
solution. Alternatively, these attributes 
could be named sex or married and 
might have values such as female and 
single. An icon has both a logical part 
and a physical part; hence, the logical 
values need not be the same as the 
physical shape. 

The iconic display function (not 
shown) then uses the current set of at¬ 
tribute values to display the object. For 
instance, the object at (3) is shown to 
be an unmarried female. When the at¬ 
tribute values of an object change, the 
object is redisplayed. This has the ef¬ 
fect of dynamically animating the execu¬ 
tion of a program. 


To develop a program, you draw a 
picture by selecting and placing all ob¬ 
jects required in the solution. Series of 
manipulations to the objects are then 
recorded as films (analagous to proce¬ 
dures). Current films are listed in the 
Films window (7). Once initiated, filming 
proceeds by recording a sequence of 
selections and actions until terminated. 

A selection is an expression that dis¬ 
criminates one or more objects or 
subobjects of the picture. When com¬ 
pleted (fixed), selections can be named 
for subsequent reuse. The Selection 
window (5) lists current selections. 

Actions transform the values of se¬ 
lected objects. When an action is condi¬ 
tional on the value of a selection, one or 


more new situations result. During film¬ 
ing, situations are recorded one at a 
time. Stacked situations are displayed 
in the Current situation window (4). 
Since actions may modify an object’s 
attributes, potentially actions might re¬ 
quire one or more objects to be redis¬ 
played, thus altering the visual image 
of the picture. In this way, the picture 
is animated to follow the execution of 
the film. 

We based this screen on Hsia and 
Ambler’s “Programming through Picto¬ 
rial Transformations," published in 
Proceedings of the 1988 IEEE Interna¬ 
tional Conference on Computer Lan¬ 
guages. 
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Construction of a 
subform in Forms 

This subform calculates the binomial 
coefficients for an order A/-1 equation. 
Starting from an initially blank form, two 
objects Coeffs and N are created by se¬ 
lecting icons from the Objects menu (7), 
dragging them into place, and resizing 
them as desired. The main cell matrix, 
named Coeffs, is an unbounded matrix. 
Both dimensions are unknown and are 
specified (5) to take the value of the 
single-cell matrix named N (6) at run¬ 
time. Thus, the evaluation of Coeffs will 
depend on the evaluation of N. This will 
force N to be evaluated prior to any 
evaluation of Coeffs. 

In this example, the value of N is a 
parameter, supplied whenever BiCoeffi- 
cient is instantiated. The computation of 
BiCoefficient is specified by four ex¬ 
pressions (1,2, 3, 4) that cover the four 
regions R1C1, RlCy, R/C1, and R/Cy 
(for i,j> 1). Once the bounds of the ma¬ 
trix are fixed, each cell in each region 
will be computed using the expression 
for that region. Cell dependencies will 
ensure that the matrix will compute cor¬ 
rectly starting from R1C1. 

When BiCoefficient is to be invoked 


from some other form, a new instance 
of BiCoefficient is created when you se¬ 
lect it from a list of subforms. For this 
new instance, the object N, which is ex¬ 
pected to inherit its value and was pre¬ 
viously blank, is now specified to be the 
value of a cell in the “calling” form from 
which we are to get the value of N, the 
matrix order. This has the effect of fix¬ 
ing the dimensions of BiCoefficient. 

The result values are bound similarly 


by selecting the matrix within the "call¬ 
ing” form that is to receive the result 
values and specifying that their values 
are to be the contents of the BiCoeffi¬ 
cient matrix. 

We based this figure on Ambler’s 
“Forms: Expanding the Visualness of 
Sheet Languages,” published in Pro¬ 
ceedings of the 1987 IEEE Workshop 
on Visual Languages. 


complete history of the computation. 
Consequently, it provides a complete trace 
of the computation and a naturally visual 
means of debugging. 

The sidebar on Forms shows the con¬ 
struction of a subform. 

Trend toward naturally visual. It is too 

early to say which of these visual language 
approaches will succeed, but clearly they 
are moving away from the idea of applying 
visual transformations to textual ap¬ 
proaches and toward the idea of naturally 
visual approaches. This trend shows gen¬ 
eral agreement with the observation dis¬ 
cussed earlier that visual techniques ap¬ 
plied to otherwise textual approaches are 
limited. 


I n the nearly twenty years since the de¬ 
velopment of Interlisp, the virtues of a 
visual, highly integrated language en¬ 
vironment have become well accepted. In 
this article we have looked specifically at 
the influence of visual technology on three 
elements of language environments: user 
interfaces, editors, and programming lan¬ 


guages. For each element, we have seen the 
transition from a strictly textual represen¬ 
tation, through relatively straightforward 
visual representations of otherwise textual 
technology, and toward new investigations 
into more naturally visual uses of visual 
technology. We assert that this trend is also 
true of other elements associated with 
language environments, such as debug¬ 
gers, interpreters, and on-line documenta¬ 
tion tools. Perhaps most significantly, vis¬ 
ual technology seems to be moving to a 
convergence between the language itself 
and the language environment, a conver¬ 
gence that goes beyond the visualization of 
existing textual approaches, a convergence 
that is naturally visual.□ 
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TurboCASE™, the fastest Macintosh 
CASE tool, turns your software devel¬ 
opment into play for $495.00. 

StructSoft, Inc., the developer of one of the top selling PC CASE tool, now marketed as Teamwork/PCSA™ by Cadre 
Technologies, Inc., is proudly announcing an integrated CASE tool, TurboCASE, for the Macintosh family of computers. 

TurboCASE is an integrated, multi-window, multi-methodology supporting CASE tool. It is extremely easy to learn and use. It 
supports Structured Analysis with or without the Real-Time extension. It will also support Data Modeling, Structured Design and 
Object Oriented Analysis and Design in the future. 

There are two versions of TurboCASE: single user version and multi-user version. The multi-user version supports importing 
and exporting project information between team members and with other CASE tools. The single user version is listed at $495.00 
and the multi-user version is $995.00. 


A demonstration diskette is available for $15.00. 
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StructSoft, Inc. 5416 156th Ave. SE, Bellevue, WA 98006. Tel: 206-644-9834 
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The joy of C-scape 


he C-scape™ Interface 
Management System frees C 
programmers from the tedium of 
coding windows, menus, data 
validation, help, and text editing 
functions. 

Moreover, C-scape is a joy to use. With 
C-scape’s object-oriented design, you’ll 
build more functional, more flexible, 
more portable, and more unique 
applications—and you’ll have more fun 
doing it. 

The industry standout. Many 

thousands of programmers have quit 
home-grown libraries and cumbersome, 
inflexible products for the pleasure of 
C-scape. The press agrees: “C-scape is by 
far the best... a joy to use,” wrote IEEE 
Computer. PC Magazine chose C-scape 
to produce its Laboratory Benchmark 

Series 5.0 software because 
C-scape offers mouse 
support. Moreover, C-scape 
simultaneously combines 
text and graphics. And because C-scape 
makes it easy to create your own custom 
routines, mqjor companies have selected 
C-scape as a standard for software 
development. 

C-scape is built around an open 
architecture, so you can use it with data 
base management or other C libraries. 


C-scape Features 

Graphics. Combine high-resolution color graphics 

Object-oriented. Add features and create 
reusable code modules. 

Mouse. Use any standard mouse for fast screen 
control. 

Portability. Write hardware independent code. 
Supports DOS, OS/2, UNIX, others. Autodetects 
Hercules, CGA, EGA, VGA. 

Text editing. Create a full featured text editor or 
pop-up note pad. 

Field flexibility. Create masked, protected and 
marked fields with complete data validation. Use 
time, date, money, pop-up list, and many more 
functions, or create your own. 

Windows. Choose from pop-up, tiled, bordered 
and exploding windows, with size and numbers 
limited only by RAM. 

Menus. Choose from pop-up, pull-down, 123-style, 
or slug menus, or create your own. 

Context-sensitive help. Link help messages to 
individual screens or fields. Cross reference 
messages to create hypertext-like help. 

Screen design. Build any type of screen or form 
with the Look and Feel™ Screen Designer, then 
automatically convert it to C. 

Screen flexibility. Call screens from files at 
run time or link them in. 


And to port from MS-DOS or OS/2 to 
UNIX, just recompile. 

Trial with a smile, e scape is not 
only the most sophisticated, flexible and 
powerful interface system available, it’s 
also the most friendly—and easiest to 
use. Try C-scape on a 30-day trial. It 
comes with a thorough manual, demo 

disk, sample programs with 
source code, an optional 
screen designer and code 
generator, access to a 
24-hour bulletin board, and toll-free 
support. No royalties, runtime licenses, or 
runtime modules. After you register, you 
get complete library source code at no 
extra cost. 

Call 800-233-3733 (617-491-7311 

in Mass.) to try C-scape now. After the 
joy of C-scape, programming wil never be 
the same. 

MS-DOS, OS/2: $299, library only; with 
Look & Feel, $399. UNIX, XENIX, Apollo, 
Sun, Stratus, others please call. 
Mastercard and Visa accepted. 
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VISUALIZATION IN COMPUTING 


A Declarative Approach to 
Visualizing Concurrent 
Computations 


Gruia-Catalin Roman and Kenneth C. Cox 
Washington University in St. Louis 


T he importance of visualization as a 
communication tool has long been 
acknowledged. Recently, how¬ 
ever, a growing consensus has emerged re¬ 
garding its potential for promoting the 
understanding of complex behaviors ex¬ 
hibited by physical phenomena and com¬ 
putations. We explore visualization — 
graphically representing objects and pro¬ 
cesses — as a means for understanding 
programs consisting of large numbers of 
concurrent processes. Indirectly, we hope 
to establish a new technical foundation for 
research into the monitoring and debug¬ 
ging of large-scale concurrent programs. 

The extremely high volume of informa¬ 
tion produced during the execution of a 
concurrent program greatly exceeds hu¬ 
man abilities to assimilate it in textual 
form. This is in part due to the sequential 
processing of textual information. The 
human visual system is more suited to 
processing information in the form of 
images. Humans can process large quanti¬ 
ties of image information in parallel, de¬ 
tecting and tracking complex visual pat¬ 
terns with incredible speed. Nevertheless, 
as the number of processes grows, the 
viewer’s ability to understand the resulting 


Program verification 
promises to provide a 
formal foundation for 
visualizing concurrent 
computations, a 
technical endeavor 
currently dominated 
by empiricism and 
aesthetics. 


image can be rapidly saturated unless the 
displayed information’s level of abstrac¬ 
tion is increased. For this reason, abstrac¬ 
tion plays an important role in visualiza¬ 
tion. By providing flexible abstractions, a 
visualization system can help the program¬ 
mer select displays that are easily specified 


and understood. 

We doubt, however, that powerful ab¬ 
stractions of concurrent computations can 
be built using the operational methods 
currently employed in program animation. 
Although helpful in understanding the 
behavior of sequential programs, opera¬ 
tional reasoning fails when faced with a 
multitude of concurrent actions that may 
be interleaved in arbitrary ways. These 
conditions require a greater reliance on 
formal verification. We will explore a 
methodology that attempts to derive visual 
representations of concurrent computa¬ 
tions from their proofs. Correctness proofs 
involve either reasoning about computa¬ 
tional sequences (for example, CSP 1 ) or 
about program states (for example. 
Unity 2 ). We consider the latter approach to 
be better suited as a foundation for visuali¬ 
zation because program states map more 
readily to images. Moreover, we expect to 
be able to render invariant properties of the 
program state as stable visual patterns and 
to render progress properties as evolving 
visual patterns. 

The departure from operational reason¬ 
ing also has important ramifications for the 
ease with which visualizations can be 
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specified. Instead of treating visualization 
as a mechanism invoked whenever 
changes in the display state are desired, 
visualization may be defined as an abstrac¬ 
tion, that is, a mapping from computational 
states to the states of graphical objects 
rendered by a display device. We will dis¬ 
tinguish between the two approaches by 
characterizing the former as imperative 
and the latter as declarative. As currently 
employed, the imperative approach in¬ 
volves actual modifications to the program 
code: Procedure calls inserted at appropri¬ 
ate points in the code trigger desired 
changes in the image being displayed. The 
declarative approach, however, promises 
to eliminate the need to alter program code 
and to accommodate runtime changes in 
the abstraction level of the information 
being displayed. 

Although the declarative approach can 
be used with any concurrent language, we 
have selected the shared dataspace 
paradigm as the underlying model of 
concurrent computation. Shared dataspace 
languages communicate among concur¬ 
rent processes via a common content- 
addressable data structure (typically a set 
of tuples) called a dataspace. Content- 
based addressing of data is common in 
artificial intelligence, and expert system 
languages such as OPS5 3 can be classified 
as shared dataspace languages. Linda 4 
became the first concurrent shared-data- 
space language to be implemented and to 
receive commercial attention. Swarm, 56 a 
language developed and used by our re¬ 
search group as a vehicle for studying 
programming and visualization meth¬ 
odologies, became the first concurrent 
shared-dataspace language to have an 
assertional-style proof logic. Swarm is 
particularly appealing for declarative 
visualization because its dataspace fully 
specifies the current program state (control 
and data) and has a simple uniform-state 
representation (a set of tuples). 

Although we use Swarm as the basis for 
our discussion, this article is not about a 
particular language or visualization sys¬ 
tem. (Actually, since efforts to implement 
Swarm and its visualization testbed on a 
hypercube-class multiprocessor are still in 
their initial phases, all images in this ar¬ 
ticle are from simulated executions of the 
various programs.) Rather, we focus on 
our concept of the future of program visu¬ 
alization. We present arguments in favor 
of the declarative visualization paradigm 
and build a case for program verification as 
the technical foundation for a formal ap¬ 
proach to visualization. 


Declarative 

visualization 

The visualization field can be divided 
into three broad areas. Visualization in 
scientific computing, or ViSC, refers to the 
animation of data such as that produced by 
supercomputer simulations, satellites, and 
measuring devices used in astronomy, 
meteorology, geology, and medicine. Vis¬ 
ual programming is the specification of 
programs in a notation using two or more 
dimensions, as by flowcharts, graphs, dia¬ 
grams, or icons. Program visualization, 
also called algorithm animation, uses im¬ 
ages to represent some aspect of a pro¬ 
gram’s execution. 

Program visualization research has been 
motivated by the desire to explain, by 
means of animated displays, the workings 
of sequential algorithms. The Balsa 7 sys¬ 
tem was designed with this goal in mind. 
Balsa was one of the earliest visualization 
systems and is still probably the best 
known and the most influential. Balsa uses 
an animator to construct visualizations. 
The animator determines which events in 
program execution should be captured and 
how they will be represented. The anima¬ 
tor then augments the algorithm with calls 
to library procedures that interface with 
the mechanics of display generation. The 
procedure calls, which are embedded in 
the existing algorithm code at points where 
the key events occur, trigger changes to the 
display. 

Balsa uses an imperative approach to 
algorithm animation. Image generation is, 
in essence, treated as a side-effect of pro¬ 
gram execution: Specific events modify 
the image in particular ways. This ap¬ 
proach, while quite successful, has the 
inherent drawback that the animator must 
modify the program code. It is also gener¬ 
ally difficult to change the information 
being displayed and the way in which it is 
displayed. Although many systems allow 
the viewer to select from several abstrac¬ 
tions provided by the animator, they do not 
permit the viewer to specify an entirely 
new abstraction. Generally, this would 
require identifying new events and mark¬ 
ing them in the code. 

Possibly in response to these difficul¬ 
ties, a recent trend is to use declarative 
methods of algorithm visualization. In 
several systems, the algorithm animator 
declares a number of graphical objects — 
usually considered to be icons — with 
parameters that can be changed by pro¬ 
gram operation. The Aladdin system 8 uses 


this approach. However, as in imperative 
systems, the Aladdin animator must still 
modify the program code to update ob¬ 
jects. 

Several other systems, by binding object 
parameters to program variables, manage 
to remove the animator’s need to modify 
the program code. Changes to the variables 
are transmitted to the visualization system, 
which changes the icons and updates the 
display. The Provide system, 9 intended for 
use in debugging, considers all potentially 
interesting aspects of algorithm behavior. 
Therefore, procedure calls inserted by the 
compiler automatically record all state 
changes. The PVS system, 10 intended for 
the monitoring of manufacturing pro¬ 
cesses, assumes all information of interest 
is stored in a database accessible to the 
visualization system. This approach has 
certain similarities to our own shared-data¬ 
space model of concurrency. 

Shared dataspace 

Before presenting the visualization 
methodology, we’ll introduce some 
shared-dataspace concepts and notation by 
means of a simple, nondeterministic, par¬ 
allel algorithm. We first express it in a 
traditional block-structured notation and 
then restate it as a shared-dataspace pro¬ 
gram, using notations borrowed from the 
Swarm language. The algorithm can be 
specified informally as follows: 

Given an array X[1.JV] of strictly posi¬ 
tive integers, compute the sum of all the 
values stored in X and place the result in 
one of the array entries; the other array 
entries should be zeroed. 

This algorithm’s first implementation is 
given in a hypothetical block-structured 
language that provides a cobegin-coend 
construct, atomic predicate evaluation, 
and conditional atomic multiple-assign¬ 
ment statements.* 

For each entry X[£] in the array we cre¬ 
ate a concurrent branch of a cobegin-coend 
construct. The branch corresponding to a 
nonzero array entry X[k] attempts to accu¬ 
mulate into X[k] the values of array entries 
having an index higher than k while simul¬ 
taneously zeroing such entries. 


‘For example, the statement if a>0 then a,b := 2,5; 
endif is logically equivalent to locking the variables a 
and b, executing the statement if a>0 then a := 2; b := 
5; endif, and then unlocking the variables. 
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N : positive natural; 

X[1..N] : array of positive natural; 

cobegin for each k:=l..N-l; 
for j:=(k+l)..N loop 
if X[k] = 0 then exit; endif 
if X[k] * 0 and X[j]*0then 
X[k], XU] := (X[k] + X[j]), 0; 
endif 
end loop; 

coend 

The execution is nondeterministic. As¬ 
suming each branch is allocated to a sepa¬ 
rate processor, the execution time, given in 
terms of nonoverlapping assignment state¬ 
ments, is at most 0(N) and at best O(logiV). 
The algorithm’s performance, however, is 
not germane to this discussion. 

The activity taking place along each 
branch k involves a search for the next 
entry X[/] having a nonzero value and the 
action of adding the value of X[/] toX[/i], as 
long as X[k\ is nonzero. Logically, the 
search requires us to evaluate the predicate 

3 j : k < j < N : X[k] > 0 a X[j] > 0 a 
-i (3 i: k < i < j : X[i] > 0) 

and to perform the action 

X[k], X[j] := (X[k] + X[j]), 0 

using the value of j bound by the predicate 
evaluation and ensuring that the predicate 
evaluation and the assignment are per¬ 
formed as a single atomic action. 

These requirements match directly with 
the definition of a Swarm transaction: an 
atomic inspection and transformation of 
the dataspace. Swarm partitions the data- 
space into several subsets. These include 
the tuple space, a finite set of data tuples, 
and the transaction space, a finite set of 
transactions. Pairing a type name with a 
sequence of values creates an element of 
the dataspace. In addition, a transaction 
has an associated behavior specification. 
Transaction execution is modeled as a 
transition between dataspaces. An execut¬ 
ing transaction examines the dataspace, 
then deletes itself from the transaction 
space and, depending on the results of the 
dataspace examination, modifies the data¬ 
space by inserting and deleting tuples and 
by inserting (but not deleting) other 
transactions. Note that a query that fails 
removes itself, leaving the dataspace 
otherwise unchanged. A Swarm program 
begins executing from a valid initial data¬ 
space and continues until the transaction 
space is empty. On each execution step, a 


transaction is chosen nondeterministically 
from the transaction space and executed. 
The transaction selection is fair in the sense 
that each transaction in the space will 
eventually be chosen. 

Returning to our summation example, 
we can store the array X as a collection of 
tuples and reformulate each cobegin- 
coend branch as a Swarm transaction. We 
can represent X in tuple form by encoding 
each array entry X[k\ with value v as a tuple 
(/t,v) of type entry. The initial tuple space 
configuration becomes 

{ k : 1 < k < N : entry(k, X[k]) } 

The predicate/action pair associated 
with branch k can be rewritten as the fol¬ 
lowing transaction. In Swarm, a comma is 
used in the place of the A operator in 
predicates. 

Sum(k) = 
l,p,v: kd<N : 
entry(k,p), entry(t,v), 

-i (38,0 : k<8<i : entry(S,o)) 

entry(k,p)t, entry(i,v)t, 
entry (k,p+v) 

This transaction differs from the original 
formulation in one important respect. In¬ 
stead of maintaining information about the 
array entries that have been zeroed (that is, 
including a tuple entry(i,0) in the data¬ 
space), we simply delete these tuples, as 
indicated by the t symbol in the action 
part. This makes the original test -i (3i : 
k<i<j : X[/]>0) simply a test for the 
presence of any tuple with index in the 
specified range. 

To complete the translation to a shared 
dataspace program, we need to ensure that 
for each k a Sum(£) transaction is initially 
in the transaction space and that successful 
transactions recreate themselves. The fol¬ 
lowing definition of the initial transaction 
space guarantees the former condition. 

{ k : l<k<N-l : Sum(k) } 

The reinsertion of Sum(&) can be added 
to the action part of the transaction: 

Sum(k)= 

t,p,v : k<i<N : 
entry(k,|i), entry(i,v), 

(38,o : k<8<i: entry(8,o)) 

entry(k,|i)f, entry(i,v)t, 
entry(k,|i+v), 

Sum(k) 


The resulting Swarm program can now 
be simplified by removing some of the 
biases inherited from the original block- 
structured formulation. There is no need to 
ensure, when adding two entries, that the 
entries in between have been zeroed — this 
condition is only an artifact of the iterative 
method used by the original program. 
Associating a transaction with each entry 
in the array (except for the last one) is also 
unnecessary. A single transaction may be 
created at the start of the program, and with 
each successful execution the transaction 
may clone itself into two distinguishable 
transactions. This method leads to an ex¬ 
ponential growth in the degree of paral¬ 
lelism employed by the program. The 
growth can be controlled by assigning each 
transaction an identifier from a finite set 
(for example, 1..N). In any case, all trans¬ 
actions eventually disappear when the 
summation is complete. Once the summa¬ 
tion is completed, the query part of the 
Sum transaction always fails and is re¬ 
moved. With these changes the Swarm 
program becomes 

Tuple space: 

( k : l<k<N : entry(k,X[k]) ) 

Transaction space: 

{ Sum(l) ) 

Transaction type definition: 

Sum(I) = 

ll,i2,pl,p2 : l<tl<i2<N : 
entry(tl,pi), entry(t2,p2) 

entry(tl,pl)+, 

entry(i2,|i2)t, 

entry(tl,pl+p2), 

Sum(tl), Sum(i2) 

Figure 1 shows a sample execution of this 
program. 

Figure 2 shows two possible visualiza¬ 
tions of this algorithm, one for the block- 
structured program and one for the Swarm 
version. Active branches of the cobegin- 
coend construct, and transactions in the 
dataspace, are represented as balls. In both 
cases there are at most N balls. Each ball 
has one parameter that defines the ball 
position along a predefined horizontal line 
in the image. In the block-structured pro¬ 
gram, each ball’s position is determined by 
the index value k associated with the par¬ 
ticular branch. In the Swarm program, the 
value I of the Sum(7) transaction deter¬ 
mines each ball’s position. 

The values associated with each array 
entry are mapped to a bar. The bar consists 
of a series of rectangles aligned next to 
each other along a predefined, horizontal 
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Figure 1. Sample execution of the 
Swarm array-summation program. 
The input array has five elements. 
Each cloud diagram represents the 
contents of the dataspace at some 
point in time. The topmost diagram 
shows the initial dataspace; the bot¬ 
tommost shows the final dataspace, 
when no more transactions exist. 
Tuples are in rectangles and trans¬ 
actions in parallelograms. This illus¬ 
tration assumes a high degree of 
concurrency. In any state, every 
transaction attempts to match the 
dataspace. 

(a) In this particular execution se¬ 
quence, the initial transaction 
Sum(l) matches the tuples entry(2,7) 
and entry(4,5). Sum(l) and the two 
tuples are removed; the tuple en¬ 
try^,12) and transactions Sum(2) 
and Sum(4) are generated. 

(b) Both Sum(2) and Sum(4) then 
successfully match, adding en- 
try(3,l) to entry(l,8) and entry(5,5) 
to entry(2,12), respectively. Four 
transactions are also added to the 
dataspace. 

(c) With only two entry tuples 
now in the dataspace, only one 
transaction can successfully match. 
The others fail and are removed 
without generating new transac¬ 
tions. The successful transaction 
adds entry(2,17) to entry(1,9). 

(d) Only one entry tuple is in the 
dataspace; both transactions fail 
and are removed. 

(e) In the final state, only the sum 
of the original five elements re¬ 
mains. 


line in the image. The length and position 
of each rectangle are determined by the 
value and the index of some entry in the 
array X. 

We choose this particular visualization 
because it captures key properties used to 
prove the correctness of the two programs: 

• The sum of the values of the array 
entries is constant, and the length of 
the bar stays constant. 

• The number of nonzero entries in the 
array is reduced by one with each 
successful assignment or transaction 
execution, decreasing the number of 
rectangles. 


• Once the number of nonzero entries 
drops to one, all active branches of the 
cobegin-coend construct terminate, 
and each transaction execution re¬ 
duces the number of transactions in the 
dataspace by one. In both cases, the 
number of balls decreases until it 
reaches zero. 

The similarity between the two proofs 
led to identical visualizations. Differences 
in the operational details are made evident 
by variations between the two sequences 
of images. 

Next, we will consider the problem of 
specifying the visualization for each of the 


two programs. In Figure 2 we used two 
types of graphical objects: 

Ball(position) 

Rectangle(position, length) 

Ball(n) indicates that the nth ball is to be 
depicted. Rectangle(n,/) indicates that the 
rectangle in position n of the bar is to have 
length /. We permit the length to be 0, and 
if a rectangle for position n is missing, a 
length of 0 is assumed. 

Object generation rules provide a con¬ 
venient way of specifying the mapping 
from program states to graphical objects. 
Given a particular program state, each rule 
defines a set of objects that must be in¬ 
cluded in the image. For example, in the 
block-structured program the set of rec¬ 
tangles is 

{ k : l<k<N : Rectangle(k,X[k]) J 
and is defined by the rule 
k : l<k<N : 

true => Rectangle(k,X[k]) 

This is to be interpreted as “for each entry 
X[fc], generate a graphical object 
Rectangle(£,X[&]).” The rectangles can be 
similarly specified forthe Swarm program: 

i,V : 1<1<N : 

entry(t,v) => Rectangle(t,v) 

The interpretation of this is similar: “for 
each tuple entry(i,V) in the dataspace, 
generate a graphical object Rec- 
tangle(t,v).” 

In the Swarm program, the definition of 
the balls is equally straightforward: 

i : 1<1<N : Sum(t) =>Ball(t) 

However, it is not immediately apparent 
how the definition might be specified for 
the block-structured program, unless addi¬ 
tional variables are added to capture the 
necessary control state information and 
encode it as data. We can introduce such 
additional variables, often called auxiliary 
variables, in the form of a Boolean array 
fi[l..N] where fl[E| is true if and only if 
branch k of the cobegin-coend is active: 

B[1..N]: array of Boolean :=true; 

cobegin for each k:=l ..N-l; 
for j:=(k+l)..N loop 
if X[k]=0 then exit; 
if X[k]*0 and X[j]*0 then 
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X[k],X[j] := (X[k]+X[j]),0; 

endif 
end loop; 

B(k) := false 

coend 

The definition of the balls for this program 
then becomes 

k ; l<k<N ; B(k) => Ball(k) 

The need to add auxiliary variables to 
properly capture the state information in 
the block-structured program highlights 
one of the advantages of the shared data- 
space paradigm: All state information is 
contained in the dataspace. 

Visual abstraction 

Declarative approaches treat the visuali¬ 
zation of computations as the application 
of a function to the computational state, 
yielding an image. We call this function 
the visualization function. The major parts 
of our visualization model 11 are the repre¬ 
sentation of the function’s domain and 
range and the method of declaring the 
function. 

Formally, the visualization function 
maps the set of all states to the set of all 
images: 

V : States -* Images 

The function could be declared in this 
manner. However, we wish to use visuali¬ 
zation as a tool for understanding compu¬ 
tations, and we feel that understanding 
results from proper abstractions. We are 
therefore primarily interested in abstrac¬ 
tion, the translation of state information 
into symbolic form. The problem of ren¬ 
dering, the representation of symbols in an 
image, is less important, although it does 
involve some interesting and difficult 
problems. 

We therefore divide the visualization 
function into two parts, an abstraction 
function and a rendering function. These 
can be formally described as 

A : States -» Objects 

R : Objects —> Images 

with the visualization function equal to the 
composition of these functions. Again, our 
primary interest is in the specification of 
the abstraction function. 

To specify the abstraction function, we 
need some information about its domain 



(a) i 1 — -1 (b) I =3 

Figure 2. Visualization of the array summation programs. These two dia¬ 
grams visualize the operation of the block-structured and Swarm programs 
for array summation. Each program is run on the same 10-element array of 
input values. 

(a) The first visualization shows the execution of the block-structured pro¬ 
gram. The initial state of the computation is at the top, and the final state is 
at the bottom. Each state consists of a bar, composed of a number of rectan¬ 
gular elements, and a number of balls above the bar. Each rectangle in the 
bar has length equal to the value stored in some element of the array, while 
each ball represents an active branch of the cobegin-coend construct. 

(b) The second visualization shows the execution of the Swarm program. 
As in figure (a), the initial state is at the top and the final state at the bottom, 
and each state consists of a bar and a number of balls. Each rectangle in the 
bar has length equal to a value stored in an entry tuple, while each ball rep¬ 
resents a Sum transaction. Note that the Swarm implementation starts with 
only one transaction. The number of transactions then grows as necessary to 
handle the amount of data to be processed. 

In both visualizations, the fact that the entire bar remains the same length 
shows correctness; the sum of all the array elements remains constant. The 
decrease in the number of rectangles in the bar, and the disappearance of 
the balls, shows progress. Array elements are zeroed, and the computation 
comes to a halt. 


(States) and range (Objects). States is the 
set of all possible computational states. In 
many paradigms for concurrent computa¬ 
tion — for example, communicating proc¬ 
esses — the state is difficult to define and 
even more difficult to capture, as it in¬ 
volves a variety of such widely separated 
and diverse data as contents of process 
memories, program counters and code, and 
message buffers. This adds unnecessary 
complexity to the process of visualizing a 
computation. 

However, in the shared-dataspace para¬ 
digm, and particularly in the Swarm lan¬ 
guage, all state information is represented 
in the dataspace. The visualization system 


can; in principle, examine the dataspace 
without interfering with the underlying 
computation. Representing all information 
as typed tuples further simplifies the para¬ 
digm compared to other models. There¬ 
fore, using the shared-dataspace paradigm 
as the computational model has definite 
advantages in declarative visualization. 

The range of the abstraction function 
(Objects) is the set of all possible symbolic 
representations of states; each such repre¬ 
sentation is a set of primitive graphical 
objects. We can extend our uniform data 
representation to Objects by representing 
each graphical object using the tuple nota¬ 
tion. A graphical object will be represented 


October 1989 


29 

































































Figure 3. Input image to region-labeling program. The 
input consists of an image divided into a rectangular 
array of pixels of various intensities. The program 
should mark all connected regions of approximately 
equal intensity with the same label. 


by a tuple rype(parameters), where the type 
specifies the general class of object (Circle, 
Line, Rectangle) and the parameters spec¬ 
ify the particular object, giving position, 
size, orientation, color, etc. 

We specify the abstraction function it¬ 
self by a set of rules having the form 

variables : query over dataspace 
list of object tuples 

where the variables are existentially quan¬ 
tified implicitly. Such a rule defines a set of 
constantly changing object tuples as fol¬ 
lows. The query is evaluated against the 
current dataspace, and for each successful 
match the variable bindings are used to 
instantiate the list of tuples on the right- 
hand side. All the resulting tuples are 
members of the set. For any state of the 
computation, the resulting set of graphical 
objects is the union of the sets produced by 
each visualization rule. 

Thus, if a new dataspace tuple is asserted 
that matches with some visualization rule, 
all resulting tuples are immediately added 
to the set of objects. Likewise, if a data¬ 
space tuple is retracted, any members of 
the set generated by a rule matching the 
tuple are immediately removed. Please 
note, though, that this is a model of our ap¬ 
proach to visualization; an implementa¬ 
tion would not necessarily compute the 
graphical objects and image in this fashion. 

Visualization 

methodology 

Our visualization methodology provides 
guidelines for constructing animations in 
the declarative model. Most systems recog¬ 
nize that certain methods of representing 
data are more effective than others, but they 
lack the concept of a methodology, at least 
in the sense of general rules for construct¬ 
ing animations. We hope to address this 
problem, and place visualization on a more 


firmly technical foundation. We base our 
methodology on program correctness. Pro¬ 
gram correctness techniques express and 
prove properties about programs with the 
dual goals of demonstrating that the pro¬ 
gram is correct and understanding why it is 
correct. 

Our rationale for using program correct¬ 
ness in our methodology is based on two 
observations. First, program correctness 
seeks to explain the behavior of computa¬ 
tions. Since our own goal is the use of 
visualization for understanding, the two 
mesh nicely. Second, program correctness 
has proved to be quite successful in its 
goals, suggesting that the translation of its 
principles to visualization might be 
equally successful. Systems forexpressing 
and proving program properties have been 
developed for several programming para¬ 
digms. 21213 A system for expressing and 
proving properties of shared dataspace 
programs has also been developed. 6 

The types of properties that can be ex¬ 
pressed in these systems fall into two broad 
categories, safety and progress properties. 
Safety properties (such as invariants) give 
conditions that the program may not vio¬ 
late. Referring to the array summation 
program, property (1) — the sum of the 
values of the array entries is constant — is 
a safety property. Progress properties tell 
what the program is required to do. Proper¬ 
ties (2) and (3) in the summation programs 
— the number of nonzero entries is stead¬ 
ily reduced, and the program terminates 
after the number of such entries reaches 
one — are progress properties. 

We believe that the same properties used 
to prove programs correct can be used to 
indicate what aspects of those programs 
should be represented in the visualization. 
Further, we believe that the structure of the 
property, as it is expressed in whatever 
proof logic is used, provides a guide to how 
that property should be visualized. At the 
highest level, this means that invariants 
would normally be visualized as stable 
patterns while progress properties would 
be visualized as evolving patterns. 


Application to 
region labeling 

To illustrate our methodology, we use 
the image-processing region-labeling 
problem. In this problem, we are given a 
digitized black-and-white image such as 
that shown in Figure 3. First, we want to 
divide this image into connected regions 
where each region’s pixels are of approxi¬ 
mately the same grey level. We then select 
one pixel from each region to identify that 
region in later processing activities. We 
can state the program requirements more 
formally as follows. 

The problem input is an M-by-N array 
(Intensity) and a function (Threshold). In¬ 
tensity represents a digitized image di¬ 
vided into pixels; it assigns to each pixel a 
value representing its brightness. Thresh¬ 
old maps the intensities to a smaller range; 
for example, given an intensity i, 
Threshold(i') might be the integer part of 
it 10. Two pixels are in the same bucket if 
the Threshold function produces the same 
result when applied to their intensities. 

Two pixels are neighbors if they share a 
side; the pixel at coordinate (x,y) neighbors 
the pixels (x-l,y>, <jt+l,y), (jt,y-l), and 
<x,y+l). Two pixels are in the same region 
if they are connected by a path of neighbor¬ 
ing pixels, all of which are in the same 
bucket. The output of the region-labeling 
program is to be an Af-by-A-array Label, 
where two pixels are assigned the same 
label if and only if they are in the same 
region. In addition, a single “master pixel” 
is to be identified in each region. 

A nondeterministic algorithm for this 
problem can be described as follows; 

Assign a unique label to each pixel 

while 

there are neighboring pixels 
pi and p2 in the same bucket, 
with p2’s label less than 
that of p\ 

loop 
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Definitions: 

Pixels = { x,y, : l<x<N, l<y<M : (x,y) ) 

Tuple space: 

(pipe Pixels : is_labeled(p,Intensity(p),p) ( 

Transaction space: 

{ p : pe Pixels : Label(p) } 

Transaction type definition: 

Label(P) = 
tl,Xl„X2: 

is_labeled(P,ll,Xl), p neighbors P, is_labeled(p,t.2,X2), 
Threshold(il) = Threshold(t2),X2<Xl 

is_labeled(P,il,Xl)t, 
is_labeled(P,t 1 ,X2) 

II 

true 

Label(P) 


Figure 4. Swarm program for region labeling. The Label(P) transaction per¬ 
forms two operations. The first operation searches for a pixel p which neighbors 
P, is in the same bucket, and has a smaller label. If such a pixel is found, the 
transaction relabels P with the label of p by removing the old is labeled tuple 
and adding a new one. 

Simultaneously with the previous operation, the predicate true is evaluated. 
This obviously succeeds, so the program adds a new Label(P) transaction to the 
dataspace. 


Relabel pi with the label of p2 

end loop 

The “master pixels” are those 
that retain their original label 

Figure 4 illustrates a Swarm implemen¬ 
tation of this algorithm. The dataspace at 
all times contains a tuple of the form 

is_labeled(P,I,L) 

for each pixel P. This tuple indicates that 
the pixel with coordinate P and intensity I 
is currently labeled with label L. Pixel 
labels are just coordinates; each pixel is 
initially labeled with its own coordinate. 
We assume that a primitive operation to 
compare two labels is provided; we use the 
symbol < for this. 

We wish to visualize the operation of 
this algorithm. The first problem with con¬ 
structing a visualization is to determine the 
graphical objects that will be used and their 
layout, that is, the arrangement of the ob¬ 
jects. In this region-labeling example, 
there is a very natural layout where pixels 
are translated into squares, and the squares 
are arranged in a grid according to the 
coordinates of the pixels. We will provide 
the squares with borders. Both squares and 
borders can be colored in various ways. 

Our graphical-object universe therefore 
consists of two object types: squares and 
borders between two squares. Both types 
of objects have properties that define their 
position and color. These can be repre¬ 
sented in tuple notation: 

Squar ^coordinate, color) 

Border( coordinate 1, coordinate 2, 
color) 

The representation of colors may be de¬ 
vice-dependent. We will assume a colorize 
function is available that maps pixel labels 
to the color space. The function is one-to- 
one, so distinct input labels have distinct 
colorization values. The range of colorize 
does not include all colors that can be 
produced by the device. Colors not in the 
range of colorize are called recognizable. 

The rendering function will translate 
collections of these objects into a screen 
image. The overall result will be a grid as 
illustrated in Figure 5. We are not inter¬ 
ested in such rendering function details as 
the mapping of square coordinates to 
points on the screen, and the determination 
of the location of borders from the two 
coordinates in the tuple. However, we will 
assume the rendering function has the fol¬ 
lowing properties: 


• If no object tuple is mapped to some 
screen point, that point is rendered in a 
recognizable color called the back¬ 
ground color. 

• If two or more object tuples with dif¬ 
ferent colors map to some screen point, 
that point is rendered in a recognizable 
color called the overlap color. 

Perhaps the most direct representation 


of the region-labeling is to map each pixel 
to a square having a color determined by its 
current label: 

VO: p,i,X: 

is_labeled(p,v,X) 

Square(p ,colorize(X)) 

Figure 6 illustrates this visualization. 








Figure 5. Layout for region-labeling 







visualization. Graphical objects of 
type Square are rendered in the 







large square regions. Graphical ob¬ 
jects of type Border are rendered in 







the smaller rectangular and square 
regions. 
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Figure 6. First visualization of region labeling. This sequence of four images visualizes the operation of the region-labeling 
program using the abstraction rule VO. Each image results from applying VO and the rendering function to the dataspace at 
some point in the computation. 

The leftmost image represents the initial state of the computation. Each pixel has a unique label and is assigned a unique 
color by the colorize function. 

The next image shows the state after some time has elapsed. Some of the pixels have been relabeled and have changed 


This rather simple visualization may ap¬ 
pear to be all that one needs to understand 
the program’s behavior. However, this 
visualization contains several flaws. It is 
impossible to tell if the final result is a 
correct labeling. The desired output of a 
“master pixel” for each region, although 
present in the data, is not in the visualiza¬ 
tion. Finally, and most severely, the dis¬ 
play captures the low-level mechanics of 
the program execution rather than the fun¬ 
damental program properties used to rea¬ 
son about the computation. 

We will now apply our visualization 
methodology to generate another visuali¬ 
zation of this algorithm (Figure 7). The 
principal invariants and progress condi¬ 
tions used in the correctness proof (not pre¬ 
sented here) for the program are: 

II: Region boundaries are stable. 

12: Two neighboring pixels belonging 
to two different regions never have 
the same label. 


13: In every region, the pixel having the 
smallest coordinate is labeled by its 
own coordinate. 

PI: If a pixel p has a neighbor belonging 
to the same region and labeled by 
the smallest label in that region, p 
will eventually be labeled by the 
smallest label in that region. 

As stated earlier, invariants are rendered 
as stable patterns such that violations of 
the invariant are easily observed. How¬ 
ever, when formally stated in a logical 
calculus, II, 12, and 13 have very distinct 
forms. II is universally quantified such 
that all region boundaries remain the same. 
12 involves a negation: it is not the case that 
two neighbors in different regions have the 
same label. 13 includes an embedded exis¬ 
tential quantification (for every region, 
there is some pixel that has the smallest 
coordinate and is labeled with its own 
coordinate). Because of this, we expect 
each to be visualized in a different manner. 


(We are currently investigating the hy¬ 
pothesis that the form of the invariant can 
be used to indicate the manner in which it 
should be visualized.) 

II requires a part of the computation 
state to remain unchanged throughout the 
computation. This strongly suggests the 
need to render this part of the state in the 
visualization; if the state changes illegally, 
the change will be detectable in the image. 
We will therefore render the region 
boundaries in some recognizable color, for 
example white. If II is violated these bor¬ 
ders will move or disappear during execu- 

We will use the layout borders to render 
the region boundaries. By using the 
eight_neighbors relationship, the small 
bordering boxes at the corners of the 
squares will be filled, largely for aesthetic 
reasons. The rule that visualizes II is 

VI: pl,tl,A,l,p2,i2,A.2: 
is_labeled(pl,tl,A.l), 


Figure 7. Second visualization of region-labeling. This sequence of four images visualizes the operation of the region-label¬ 
ing program using the abstraction rules VI through V4. The two program runs in Figures 6 and 7 are identical, and corre¬ 
sponding photographs were taken after equal amounts of computation; only the visualization differs. The bright yellow, 
overlap (error) color does not appear because the program and implementation ran correctly. 

The leftmost image represents the initial state of the computation. The boundaries between regions are clearly shown in 
white (by VI). Each pixel has its own coordinate-as-label, and so is colored by V3. V4 renders the borders between pixels in 
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color. Note that small regions of the same color are beginning to form. 

The third image shows the state after additional time has elapsed. The relabeling has continued, and the regions of the 
same color have grown larger. 

The fourth image shows the state when the computation has completed. Two pixels have the same label (are the same 
color) if and only if they are in the same region. 


is_labeled(p2,i2,X2), 
pi eight_neighbors p2, 
Threshold(tl) * Threshold(t2) 

Border(pl,p2, white) 

Invariant 12 expresses a condition that 
must not occur. We therefore detect viola¬ 
tions of 12. This can be done by rendering, 
in a recognizable color such as the overlap, 
the border between any two neighboring 
pixels that violate 12. This rendering is 
accomplished by the rule: 

V2: pl,ll,p2,i2,X: 

is_labeled(pl,tl,X), 
is_labeled(p2,i2,X), 
pi neighbors p2. 

Thresholds 1) * Threshold(l2) 

Border(p 1 ,p2,overlap) 

Visualizing 13 seems to cause difficul¬ 
ties, because the invariant refers to a pixel 


that, although known to exist and to be 
unique for each region, must be precom¬ 
puted. However, a closer examination of 13 
shows that this invariant specifies the 
“master pixel” in each region — a pixel that 
is only identified when the algorithm has 
completed. 13 can therefore be visualized 
by introducing some initial uncertainty that 
is eliminated as the computation pro¬ 
gresses. The idea is to color all pixels that 
retain their initial label assignment. Ini¬ 
tially all pixels are colored; as the program 
proceeds, pixels revert to the background 
color, leaving only the pixel with the small¬ 
est coordinate (the master) colored. The 
following rule can be used for this: 

V3: p,t: 

is_labeled(p,t,p) 

Square(p,colorize(p)) 

Progress properties are to be captured by 
pairs of patterns, such that a state generat¬ 


ing the first pattern will lead to a state 
generating the second pattern. To repre¬ 
sent PI, we wish to capture the idea that if 
some pixel p can be relabeled, it eventually 
will be relabeled. This can be visualized by 
marking the boundaries between pixels 
that are in the same region, but have differ¬ 
ent labels, with some recognizable color 
such as red. Progress is recognized by the 
reduction in the total number of red 
boundaries: 

V4: pl,tl,Xl,p2,i2,X2: 
is_labeled(p 1 ,i 1 ,Xl), 
is_labeled(p2,i2,X2), 
pi neighbors p2, 

Threshold 1) = Threshold(t2), 

X1*X2 

Border(pl,p2,red) 

Examining all four of these rules to¬ 
gether, VI outlines the boundaries of the 
regions in white, V2 detects violations of 


the same region, but with different labels, in red. 

The next two images represent the state after some time has elapsed. Some of the pixels have been relabeled. Those that 
do not retain their original label have disappeared, as V3 no longer renders them. The white borders have not changed. 
The number of red borders has steadily decreased, indicating progress. 

The fourth image shows the state when the computation has completed. No pixels can be relabeled, as indicated by the 
total absence of red boundaries. The single, master pixel in each region is clearly indicated by V3. 

























































































Figure 8. Visualization of polygon-construction free of intervention. This sequence of images visualizes the operation of a 
program that constructs polygons representing the edges of an image. The sequence shows several states of the computa¬ 
tion for a small portion of the image. The earliest state is at the left. The visualization is overlaid on a black-and-white pho¬ 
tograph of the terrain being scanned. 

Processing of a particular edge pixel occurs in four distinct phases, as discussed in the text. In this sequence of images all 


the desired output properties, V3 marks the 
pixel having the smallest label in each 
region and thus the final master pixel, and 
V4 marks the boundaries between pixels 
that are in the same region but have differ¬ 
ent labels. As the algorithm progresses, the 
areas within red boundaries expand toward 
the white boundaries. The disappearance 
of all red boundaries marks completion. 
Figure 7 depicts a visualization of the re¬ 
gion-labeling program in which rules VI 
through V4 are in effect. 

This simple example demonstrates the 
use of formal program properties as the 
basis for deciding which visualization 
rules are appropriate. We hope that this 
approach will lead to the development of a 
set of general rules for constructing pro¬ 
gram visualizations based on the structure 
of the properties used in the program cor¬ 
rectness proof and not on knowledge of the 
operational details of the program. Such an 
approach would aid true exploration and 
understanding of the program. 


Intervention semantics 

During monitoring and debugging of 
concurrent programs, one must minimize 
the degree of interference with the pro¬ 
gram execution to avoid altering the phe¬ 
nomenon being observed. However, when 
using visualization to study and under¬ 
stand concurrent computations, the nonin¬ 
terference requirement can be relaxed 
somewhat. This is because there are no 
errors that could be masked by slight 
changes in the order in which events occur. 
The questions we want to address here are: 
What interventions are permissible, and 
how do we guarantee that they do not 
change the semantics of the program being 
observed? 

To answer these questions, we must 
consider the underlying model of concur¬ 
rency used to define the semantics of the 
language and to construct the proof sys¬ 
tem. Most models of concurrency, includ¬ 


ing the operational model employed by 
Swarm, have no notion of time. They rely, 
instead, on fairness and atomicity assump¬ 
tions. In Swarm, for instance, each transac¬ 
tion present in the dataspace is eventually 
executed, and its execution is an atomic 
transformation of the dataspace. This 
means that one has a great degree of lati¬ 
tude in changing the scheduling policy, the 
order in which transactions are selected 
and executed, without fearing any changes 
in the program semantics, as long as fair¬ 
ness is preserved. Since the notion of fair¬ 
ness itself is a very weak requirement — 
each transaction is eventually executed — 
certain transactions may be ignored for 
very long periods of time while others may 
be selected quickly. 

We are only now starting to consider the 
implications of manipulating the schedul¬ 
ing policy on the visualization methodol¬ 
ogy. Consider, for instance, the sequence 
of photographs shown in Figure 8. They 
depict several states in the execution of a 



Figure 9. Visualization of polygon-construction with scheduling restrictions. The program from Figure 8 is run on the same 
portion of the image, but the scheduling policy has been changed to force each phase to complete before the next begins. 
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phases are allowed to operate simultaneously. Thus, we see newly created pixels (the red and blue pixels to the left of the 
image), nonedge elimination (the red pixels and some blue pixels disappear), master selection (the multicolored pixels, 
which change color as they are relabeled), and polygon construction (the blue growing lines and red final lines). Overlap 
among the four phases makes understanding the computation more difficult. 


relatively complex program.* The pro¬ 
gram assumes an airborne platform that 
scans an airport below, constructing an 
image that is unbounded on one side. For 
presentation purposes, we show only a 
small area of the unbounded image. A 
hardware edge-detector transforms the 
incoming image into a binary-edge image, 
which the program converts to a symbolic 
representation as polygons. 

Although this visualization captures 
faithfully the order in which actions would 
occur in an actual execution, different parts 
of the image are in different processing 
phases, which makes the understanding of 
the program difficult for someone seeing 
the visualization for the first time. In Fig¬ 
ure 9, the same visualization rules are 
applied to the same program, but the sched¬ 
uling policy has been altered. For a finite 
portion of the input image, transactions are 
being delayed in a manner that reveals the 
logical sequence of operations associated 
with each pixel in the input image: 


(1) A hardware edge-detector trans¬ 
forms the incoming image into a 
binary-edge image. 

(2) Nonedge pixels and edge pixels 
having three or more neighboring 
edge pixels are eliminated. 

(3) As a preliminary step to generating 
the polygons, a version of the re¬ 
gion-labeling program selects a 
master in chains of connected edge 
pixels. 

(4) The master defines the starting point 
for the polygon construction along 
each chain. 

The scheduling policy imposed in Fig¬ 
ure 9 inhibits, over a small area of the 
image, the execution of any transaction 
involved in performing one of the process¬ 
ing phases listed above until all transac¬ 
tions associated with the preceding phase 
terminate. Since the processing associated 
with each phase is independent of the 
subsequent phases, and is completed in a 


finite number of steps for any bounded 
image, the fairness of the execution is 
preserved. This would not be the case if the 
scheduling restrictions were applied to the 
entire image; because the image is un¬ 
bounded to one side, the input phase would 
never terminate. 

This example shows that schedule ma¬ 
nipulation can become an important com¬ 
ponent of a visualization methodology 
aimed at exploring properties of concur¬ 
rent computations. Yet an appropriate 
methodology and associated support tools 
for the investigation of such manipulations 
must still be developed. 


♦This particular program was actually written in a 
shared-dataspace language called SDL, the predeces¬ 
sor of Swarm. Because the visualization does not 
change under recoding into Swarm, we take the liberty 


These images show the computation midway through each of the four phases. The separation of concerns enhances under¬ 
standing of the program’s operation. 



October 1989 


35 


















T hat visualization can play a key 
role in the exploration of concur¬ 
rent computations is central to the 
ideas we have presented. Equally impor¬ 
tant, although given less emphasis, is our 
concern that the full potential of visualiza¬ 
tion may not be reached unless the art of 
generating beautiful pictures is rooted in a 
solid, formally technical foundation. We 
have shown that program verification pro¬ 
vides a formal framework around which 
such a foundation can be built. Making 
these ideas a practical reality will require 
both research and experimentation.- 
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VISUALIZATION IN COMPUTING 


Visualizing Performance 
Debugging 


Ted Lehr, Zary Segall, Dalibor F. Vrsalovic, 
Eddie Caplan, Alan L. Chung, and Charles E. Fineman 
Carnegie Mellon University 


D esigning computations to perform 
efficiently is usually an iterative 
task alternating between measur¬ 
ing and modifying the performance of 
successive computation prototypes. This 
iterative performance tuning, called per¬ 
formance debugging , can be done in sev¬ 
eral ways. 

At the start, programmers may gather 
general statistics on metrics, such as the 
average amount of parallelism in their com¬ 
putations. Averages are large-grain reports 
of what computations do and, as such, of¬ 
ten reveal only hints of trouble. 

Let us assume we have designed an 
eight-process computation. If it manages 
an average parallelism of, say, 2.1, then 
there is probably a problem. However, the 
average does not point directly to where the 
problem lies. Embellishing averages with 
other statistics, such as measures of spread, 
improves matters, but doing so may raise 
more questions than it answers. 

The additional statistics may suggest 
that the degree of parallelism exhibited by 
a computation is not only small but also 
varies widely, raising the specter of erratic 
performance. Does the computation occa¬ 
sionally hit synchronization barriers, forc¬ 
ing some of its processes to wait? When 
does it do this and how often? These are 
questions statistical information can raise, 
but programmers would still be hard- 
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Visualization of 
concurrent program 
performance is critical 
for fast, correct 
debugging. Both 
powerful and pragmatic, 
the Parallel 
Programming and 
Instrumentation 
Environment (PIE) 
provides complete 
support for 
visualization. 


pressed to obtain answers if they’re only 
provided such statistical information. 

Because of the limited information con¬ 
tained in averages and other statistics, 
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programmers must pry into the collection 
of data that yields the statistics. They must 
sift through the records, searching for 
suspicious data that might indicate anoma¬ 
lous instances of exceptional or degenerate 
performance. They must look at individual 
cases of scheduling and communication 
costs. If they have not collected the proper 
data, they must run additional experi¬ 
ments. All in all, this is a tedious, time- 
consuming endeavor. 

The tedium arises because of human 
limitations in conceptualizing relation¬ 
ships between mountains of raw numerical 
data and the objects they characterize, in 
this case, computational constructs. Elimi¬ 
nating this tedium is essential to making 
performance debugging a productive ac¬ 
tivity. The raw numerical data must be 
distilled into a form that programmers will 
readily grasp. To productively debug the 
performance of their computations, pro¬ 
grammers must be able to visualize that 
performance. 

Just as measuring performance can be 
done in a number of ways, visualizing 
performance takes several forms. For ex¬ 
ample, the histogram in Figure 1 shows the 
distribution of the degrees of parallelism in 
a hypothetical eight-process computation. 
It illustrates that only about 20 percent of 
the execution ran with a parallelism of 
three. It reveals more than straight numeri- 
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cal statistics in raising the possibility of a 
performance problem. It is fairly clear that 
the computation never even comes close to 
eight-way parallelism. 

However, the histogram does not tell 
when the various degrees of parallelism 
occur or what the rest of the computation is 
doing at those times. Trying to answer the 
question of “when,” the performance view 
shown in Figure 2 further sharpens the 
debugging scalpel by plotting the amount 
of parallelism versus time during an im¬ 
portant period in the computation. The 
edge this kind of visualization has over the 
histogram is clear. A programmer immedi¬ 
ately sees how much parallelism the com¬ 
putation can muster at different moments 
in its execution. 

This is the primary advantage of pre¬ 
senting performance data in a visual form: 
programmers interpret performance data 
more quickly. At the start of the measured 
period, for example, it is quite obvious that 
the computation manages to get parallel¬ 
ism of about four or five but quickly plum¬ 
mets to a fairly steady level of around two. 
Even though this timeline helps answer the 
question of when parallelism occurs, a 
problem remains: the programmer needs 
more information to determine precisely 
where in the program this behavior occurs. 

The parallelism timeline does not tell 
the programmer what the computation was 
actually doing during the periods of poor 
parallelism. If programmers are to know 
what computations do at particular times, 
they need to be able to visualize executions 
on the level they program in. Because 
programmers know their programs by the 
constructs and abstractions with which 
they designed them, a vital characteristic 
of the presentation of performance data 
must be a visual mapping that vividly 
draws the connection between the data and 
the computational constructs responsible 
for them. If programmers are to visualize 
the performance of computations, visual 
representations of performance data must 
be mapped onto visual representations of 
the corresponding program constructs. 

This article examines a special software 
development environment called the Par¬ 
allel Programming and Instrumentation 
Environment. 1 PIE is designed to develop 
performance-efficient parallel and sequen¬ 
tial computations.* Following an explana¬ 


* A performance-efficient computation is a computa¬ 
tion that decomposes onto a target set of computing 
resources so the resources are well-matched to the 


Fraction of 
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Figure 1. Distribution of parallelism in computation (measured at regular inter¬ 
vals). 



tion of PIE’s general theory and features, 
we reveal that the hypothetical eight-proc¬ 
ess computation we have been discussing 
is actually a real one, and we use PIE’s 
visualization tools to isolate and repair its 
parallelism problem. 

After showing PIE’s value in fixing the 
computation’s parallelism problem, we 
discuss two more difficult examples using 
PIE. The examples use slightly modified 
versions of the repaired computation exe¬ 
cuting under different circumstances. We 
round out our discussion of performance 
visualization by discussing some of the 
issues involved in correctly presenting 
visual information, such as the features 
users ask for and what can be done about a 
performance monitor’s perturbation of 
computations. Finally, we discuss the fu¬ 
ture directions of PIE. 


The PIE system: A 
visual programming 
environment 

Automatic assistance for visually pro¬ 
jecting performance data onto program¬ 
ming constructs is practically necessary 
for visualization to accelerate the perfor¬ 
mance debugging task. Bringing together 
programs and their performance data is 
best done by systematic software develop¬ 
ment environments that integrate different 
data analysis tools into one package pro¬ 
viding a “computational laboratory” in 
which programmers can easily design ex¬ 
periments to test the behavior of their 
computations. 

A software development environment 
for performance debugging is not effective 
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Figure 3. Organization of PIE. 


if it compels its users to vigorously search 
for performance degradation problems, es¬ 
pecially for problems that could be easily 
revealed by automatic techniques. On the 
other hand, an environment that impu¬ 
dently makes qualitative judgements about 
a computation’s performance without the 
user’s permission may annoy and mislead 
the user. The proper role of an environ¬ 
ment, then, is to present the information it 
retrieves about computations in forms that 
assist users in making their own qualitative 
judgements about how their computations 
behave. 

PIE is a software development environ¬ 
ment for debugging performance that pro¬ 
vides programmers ways to observe how 
computations execute by making use of 
special development and runtime visuali¬ 
zation tools. PIE is not just a programming 
environment, as defined by Dart et al., 2 
that only supports the development of 
program coding like, for example, the 
CODE (Computation-Oriented Display 
Environment) 3 and PV (Program Visuali¬ 
zation) 4 projects. Rather, PIE supports a 
comprehensive software development 
methodology extended to the analysis, 
verification, and validation of a 
computation’s performance. 

The philosophy of PIE. The PIE system 
is a theoretical framework for developing 


techniques to predict, detect, and avoid 
performance degradation. Underlying the 
development of these techniques is a pro¬ 
gramming paradigm in which functional 
and performance behavior is made visible 
through automated system support. 

PIE is not a program simulation environ¬ 
ment. As with the Faust project, 5 PIE’s 
designers have developed techniques for 
efficiently mapping parallel applications 
onto specific architectures and observing 
them when they execute. Although a body 
of PIE theory has been developed dealing 
with the prevention 6 and avoidance of per¬ 
formance bottlenecks, most of the work 
presented here will deal with detection 
techniques. 

Figure 3 depicts PIE’s general organiza¬ 
tion. PIE is implemented on top of Mach, 7 
an operating system under development at 
Carnegie Mellon University for support¬ 
ing parallelism; nonetheless, PIE can be 
ported to other Unix-like operating sys¬ 
tems. It supports languages such as C, 
MPC, 8 C-threads, 9 Ada, and Fortran. 

Unlike some other performance-mea¬ 
suring environments, 10 PIE is not architec¬ 
ture specific. Rather, it is a portable system 
whose basic platform is a workstation run¬ 
ning the X Window System with a mini¬ 
mum of 8 megabytes of RAM and a 70- 
megabyte hard disk drive. (Our PIE sys¬ 
tems are configured with 12 megabytes of 


RAM and 400-megabyte hard disk drives.) 
PIE’s monitoring instrumentation runs on 
a diverse set of hardware platforms, in¬ 
cluding VAX and Sun workstations, En¬ 
core Multimax, and Warp. 

Using PIE. Assume the programmer has 
a problematic matrix multiply computa¬ 
tion executing on a 16-processor, shared- 
bus architecture that exhibits the parallel¬ 
ism problem described earlier. The pro¬ 
grammer wants to know why the 
computation’s average parallelism is only 
2.1, especially since eight multiplier pro¬ 
cesses are spawned.’ 

The basic structure of the computation 
consists of well-partitioned parts of two 
matrices passed to several subprocesses. 
Each process first examines the size of the 
submatrices and decides whether the parts 
are small enough to operate on without 
further partitioning them and passing them 
on to another process that it spawns. After 
making the decision, the process iterates 
through its submatrices, multiplying each 
pair of rows and columns and writing out 
the result. 

Figures 4 and 5 showcase how PIE im¬ 
plements visualization of programming 
constructs. Figure 4 depicts parts of the 
text of the computation via three windows 
of a special Gnu-emacs based PIE editor. 
The program is written in an extended C 
language called MPC, which supports 
parallelism using constructs that imple¬ 
ment actions such as sharing of global 
memory. Although PIE supports lan¬ 
guages like Ada and Fortran, we chose 
MPC for this example because of its sim¬ 
plicity and capacity to express parallelism. 
It is not important to fully understand the 
semantics of the text, but some elucidation 
of the more novel parts will help. 

Briefly, the top window of Figure 4 
shows a section of the definition of the 
computation’s multiplier procedure, 
multproc. It includes a variable declaration 
of the type multiply, an instance of what 
MPC calls an activity or act, as shown in 
the middle window. Activities are process- 
like units of parallel work which, when 
spawned from the same program, are able 
to share and operate on global memory. 

Notice that multiply contains a call to 
multproc. Multproc implements the basic 
matrix partitioning and multiplying func¬ 
tions described above. After the value of an 
element of the result matrix is calculated, it 
is written out using put, shown in the low¬ 
est window, which is an instance of an 
MPC function type called opr that is used 
to operate on global memory. Entities of 
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Figure 4. Part of a matrix multiply program text. 



Figure 5. Part of the visual representation of a program. 


this type may be shared by several activi- 

The only feature of put that must be 
understood here is the sync function, a 
special MPC function that enforces mutual 
exclusion on global operations. Here, sync 
ensures that only one result may be written 
back to global memory at a time. 

Figure 5 shows PIE’s automatically gen¬ 
erated visualization of the matrix 
multiplier’s principal constructs. Each box 
in Figure 5 has a corresponding textual 
entry in Figure 4. In fact, when a box is 
touch-selected by a mouse, as is shown by 
the enlarged border surrounding the box 
labeled [c] multproc, the editor window 
automatically moves its cursor to the head 
of the corresponding textual construct, in 
this case, a call to the multproc procedure 
as shown in Figure 4. 

After PIE has visualized the constructs 
for the programmer, it is time to gather per¬ 
formance information. PIE can generate 
performance views like the histogram and 
time plot shown in Figures 1 and 2, but 
these are ancillary to a grander, more infor¬ 
mative format we will show shortly. When 
a computation with a potential parallelism 
of eight can get only two or three processes 
to run simultaneously, the programmer 
knows that he or she should investigate the 
computation’s synchronization points. 
The programmer decides to monitor any 
program construct that might force a multi¬ 
plier to wait, namely the sync just dis¬ 
cussed and the join (an example appears in 
the top window in Figure 4) that a multi¬ 
plier executes when it wishes to join its 
children. 

Getting this information with PIE is 
simple. Figure 6 shows a number of dark¬ 
ened boxes, [A] multiply, [S] Sync, and 
several cases of [J] Join. The [A] multiply 
represents the multiplier processes and [S] 
Sync is the synchronization function in the 
put operation discussed earlier. Each [J] 
Join represents an instance of a join func¬ 
tion. The darkening of these boxes indi¬ 
cates that the programmer, using a mouse- 
click, has selected them for automatic ob¬ 
servation during execution. 

Now, the programmer must run the 
program to get some data. PIE’s theoreti¬ 
cal foundations for instrumenting pro¬ 
grams" includes software, hardware, and 
hybrid event sensors. Currently, however, 
programs in PIE are instrumented using 
only software sensors. During runtime, 
PIE ensures that, when a selected construct 
executes, important information is auto¬ 
matically collected about the construct via 
a sensor and an independent collector pro¬ 


cess. For example, time stamps are re¬ 
trieved at the beginning and ending of each 
multiplier process (multiply). 

As noted earlier, PIE presents the per¬ 
formance information in a variety of ways, 


including histogram and timeline formats. 
Although such formats are incomplete and 
imprecise representations of the behavior 
of computations, they distill performance 
data into visual forms for quick and trac- 
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Figure 6. Using the visual representation to enable sensors. 



Figure 7. Part of a parallel execution of the computation on a 16-processor ma¬ 
chine (top) and a PIE editor window (bottom). 


table detection of performance problems. 

A better way to achieve more precise 
identification of performance problems is 
to use the upper view shown in Figure 7, 


PIE’s principal format for visualizing per¬ 
formance data. In this view, time is mea¬ 
sured in microseconds on the horizontal 
while the processes of the computation are 


ordered on the vertical. This particular 
view shows only the part of the execution 
from about 5.6 to 6.5 seconds (the entire 
multiplication section of the computation 
is shown in the top view of Figure 8). The 
concatenation and occasional “overlap” of 
several colored rectangles, each represent¬ 
ing a particular episode in the process’s 
history, depicts the execution of each pro- 

A rectangle “overlaps” another rec¬ 
tangle if the entity represented by the rec¬ 
tangle in the forefront is contained within 
the entity represented by the rectangle be¬ 
hind it. For example, in the upper view of 
Figure 7, waits due to a sync show up as 
yellow rectangles alternating with several 
dark rectangles. The yellow rectangles are 
actually “in front of’ of a single dark rec¬ 
tangle representing the generic body of the 
process. The green rectangle in main is an 
instance of a process waiting to join a 
child. 

When the mouse selects any rectangle, 
the cursor in the PIE editor automatically 
moves to the head of the corresponding 
construct in the program text. Here, for 
example, a sync-wait rectangle has been 
clicked on (as shown by the “sync-wait” 
message in the bottom of the small text 
window immediately beneath the rectan¬ 
gular patterns). Simultaneously, the cursor 
in the PIE editor window, shown in the 
bottom view of Figure 7, is moved to the 
head of the appropriate sync definition. 
The programmer can now analyze the 
computation’s performance using data 
automatically projected onto the 
computation’s structures. This completes 
the mapping of performance data onto 
program constructs. 

Only some of the row/column multipli¬ 
cations performed by the entire computa¬ 
tion are shown executing in the upper view 
in Figure 7. As the green rectangle indi¬ 
cates, main is waiting to join the other 
processes. The multiply processes, num¬ 
bered in the order they are spawned, exe¬ 
cute the multproc procedure. A special PIE 
process used in gathering performance 
data has been left out of this view to sim¬ 
plify this example (it would have been 
numbered “1”). 

As expected, the figure shows that, at 
any given time, several of the processes are 
waiting. If a vertical swath is drawn 
through the view at any point, it intersects 
only two or three black rectangles, indicat¬ 
ing that only those processes are doing 
useful work. The fact that the remaining 
processes are all executing sync-waits at 
these points (excepting main, of course). 
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casts suspicion on the sync function in the 
put operation as the source of the perfor¬ 
mance degradation. 

How does the programmer repair the 
program? Is the sync really necessary? 
Each time the put operation is called, after 
all, it only fills a single location in the 
result matrix. Since the matrices are well 
partitioned, each call to put touches a 
unique location. Consequently, the sync is 
not necessary. 

The top view of Figure 8 shows the en¬ 
tire multiplying section of the computation 
after removing the sync. The bottom view 
shows the original computation before this 
repair. The “squiggles” in the bottom view 
represent moments of insufficient graphi¬ 
cal resolution where one or more events 
occur, but are otherwise unimportant. The 
views show that the execution time has 
been cut from about nine seconds to just 
under one second. The PIE-generated par¬ 
allelism plot for the repaired computation 
in Figure 9 shows that the average parallel¬ 
ism has increased. 

This example was simple and perhaps 
contrived; the programmer’s error of en¬ 
forcing mutual exclusion on the matrix 
writes is a mistake only a novice would 
make. Nevertheless, it has shown the value 
of being able to visualize what a computa¬ 
tion is doing. 

Our next two examples are more rigor¬ 
ous and detailed illustrations of the value 
PIE brings to both designing and under¬ 
standing computations. Together they are 
dramatic demonstrations of the advantage 
of being able to visualize the performance 
of computations. 


Analytical and 
pedagogical uses of 
visualization 

The simple example just discussed is not 
a very exciting instance of using PIE. Our 
next examples, however, examine two 
cases of how an operating system kernel 
and user runtime affects the performance 
of computations. 

The first example analyzes what effect a 
change in a uniprocessor’s scheduling 
algorithm has on a sequential computation. 
The computation is the corrected matrix 
multiplier we just discussed. The kernel is 
Mach. The example uses specially 
equipped versions of Mach that permit the 
creation of kernel monitors for detecting 
and recording the context switches of se¬ 



Figure 8. Parallel executions of the computation with and without synchroniza¬ 
tion. 



zation. 


lected threads. 12 The computation and 
kernels both execute on a VAXstation II 
booted in single-user mode to reduce the 
number of threads** that compete with the 


** Threads are process-like Mach entities which, when 
spawned in parallel, can share global resources. Here¬ 
after, we use “thread” to designate any process-like 


computation for the machine’s processor. 

The second example dramatically illus¬ 
trates what happens when two parallel 
computations compete for the same pro¬ 
cessors on a shared-bus multiprocessor 
machine. The selected PIEScope views are 
pedagogic glimpses of what a simple 
multiprocessor scheduler does when the 
number of schedulable, parallel threads is 
greater than the number of available pro¬ 
cessors. 
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Figure 10. Three matrix multiplication executions: Ancient Kernel (top); Old 
Kernel (middle); New Kernel (bottom). 


Examples of kernel visualization: Un¬ 
derstanding the figures. The three views 
in Figure 10 are PIEScope displays of the 
repaired matrix multiplier computation 
executing on three similar, but slightly 
different, versions of Mach. The PIEScope 
views show the kernel layer, a layer of 
performance information not included in 
the introductory example. To display these 
views, PIE monitored the creation and 
termination of each of the computation’s 
threads as well the context-switching 
among them. 

Each view includes a thread, the collec¬ 
tor (not shown previously), which records 
user and kernel events belonging to the 
computation. It is created and terminated 


by main independently of the computation 
using special libraries linked with the com¬ 
putation at compile time. Although the 
collector obviously perturbs the 
computation’s performance by increasing 
its execution time, it is not a unique source 
of perturbation for the scheduler since it 
can be treated as merely another schedul- 
able thread. Later, however, we discuss 
how to compensate for the perturbation of 
user-level computations by the collector 
and other monitoring objects. 

In the Figure 10 views, black rectangles 
represent periods when the threads are 
running, and white rectangles represent 
the periods when they are not. Because the 
views depict uniprocessor executions. 


cutting a vertical swath through a view at 
any point would slice through only one 
running thread ... only a single black rec¬ 
tangle. 

Time sharing and spawning on three 
Mach kernels. The top view in Figure 10 
depicts a VAXstation II execution of the 
matrix multipier on a kernel officially 
labeled XF29 that we refer to as Ancient. 
The middle view depicts the same compu¬ 
tation on a more recent kernel designated 
CS3c, hereafter referred to as Old. The 
bottom view shows the computation exe¬ 
cuting on a kernel very similar to Old but 
with an improved thread priority evalu¬ 
ation policy. Its official name is CS5a, but 
we refer to it as New. Each of the views 
contains a pair of time cursors that measure 
the time between them. Because the 
VAXstation II clock is accurate to only 
10,000 microseconds, times displayed by 
PIEScope that are less than 10,000 micro¬ 
seconds are estimates. 

The three views show that, despite some 
similar behavior, the computation does not 
behave identically on any of the three. The 
top view shows Ancient’s scheduler giv¬ 
ing generally short, uniform time slices to 
its threads. It uses a simple scheduling 
algorithm that usually switches threads 
every 100 milliseconds. 

On the other hand, the lower two views 
show that Old and New occasionally run 
threads for several seconds, as evidenced 
by longer times slices allocated to the 
multipliers in the later stages of their exe¬ 
cution. (The “squiggles” displayed in the 
initial stages of each view will be dis¬ 
cussed shortly.) The schedulers of Old and 
New use a progressive algorithm that 
gradually increases the time slices it allo¬ 
cates to diminish context switches. 

During the first moments after the multi¬ 
ply threads are spawned on Old and New, 
there is regular context-switching among 
all the threads, much like the behavior of 
the threads on Ancient. After a while, how¬ 
ever, Old and New (especially Old) gradu¬ 
ally schedules each thread for longer and 
longer periods before switching them out. 
New differs slightly from Old in how its 
progressive algorithm evaluates thread 
priority. This difference shows up most 
dramatically when we more closely exam¬ 
ine what happens when the multiply 
threads are spawned. 

Figure 10 shows quite clearly that Old 
and New successively spawn the first three 
multiply threads more quickly than An¬ 
cient. They also show that the Old kernel 
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eliminates the context-switch “flutter” 
(where a thread frequently context- 
switches to itself) that occasionally occurs 
in Ancient just as a thread is forked off. 
The top view, for example, shows multiply 
threads 2, 3, and 4 undergoing consider¬ 
able context switching soon after they are 
spawned by Ancient. 

In addition to the advantages Old and 
New enjoy over Ancient, they each have 
some drawbacks. Old, for example, has 
problems time sharing threads equitably. 
The middle view of Figure 10 shows that, 
just before the first multiply thread is 
forked off, Old switches out the collector 
and does not run it again until nearly all the 
other children terminate. Ancient, on the 
other hand, equitably time shares the col¬ 
lector with the freshly spawned children. 

Old’s progressive algorithm also risks 
delaying thread execution. Recall that the 
first multiply thread is forked off by main, 
not by the collector. After spawning the 
thread, main does a join and switches out, 
waiting for its children to finish. Old, how¬ 
ever, does not let the first multiply thread 
run until after giving the collector an exe¬ 
cution time-slice of more than four sec¬ 
onds. Ancient, however, forks the first 
multiply thread after only three-fifths of a 
second. 

New’s thread priority evaluation policy 
compromises between Ancient and Old. 
New also time shares the collector with the 
multipliers, as does Ancient, but it attempts 
to give larger time slices, as does Old. New 
extends the compromise by reducing Old’s 
delay in forking off the first multiply 
thread. 

Moreover, threads running on Old and 
New seem to suffer from context-switch 
flutter. The views in Figure 11 show the 
first seconds of the start of each of the 
executions. They reveal that the 
“squiggles” in Figure 10 are hiding differ¬ 
ent behavior on each of the kernels. The 
views show that, despite good intentions, 
the progressive algorithms of Old and New 
fail to dramatically reduce the number of 
context-switches because they permit 
threads to switch to themselves repeatedly 
as indicated by the preponderance of 
“squiggles.” 

The utility of the views. To the designer 
of these schedulers (David Black of the 
Mach project was the principal architect of 
the scheduling changes that differentiate 
the Ancient, Old, and New kernels), views 
like those we showed confirmed that the 
changes performed as he specified. Al¬ 
though New suffers from the curious prob¬ 


lem of context-switch flutter, solutions to 
this problem are being addressed and cor¬ 
roborated using PIE. 

Before moving on to our next example, 
it is important to note the utility of these 
PIE visualizations. PIE introduces a pow¬ 
erful form of performance analysis to users 
and scheduler designers. The views just 
discussed quickly reveal some of the ad¬ 
vantages and disadvantages of each of the 
scheduler solutions. However, the compu¬ 
tations ran on a uniprocessor machine, and 
the central aim of PIE is support for the 
development and analysis of parallel 
computations. Next, we present an ex¬ 
ample of matrix computations executing in 
parallel. 

Saturating a multiprocessor. Mul¬ 
tithreaded computations execute differ¬ 
ently on multiprocessors than on uni¬ 
processors. The fundamental difference is 
in how many processors are time-shared 
by the threads. On a uniprocessor, only one 
thread may execute at a time, each waiting 
for the scheduler to decide which is next. 
Despite anything a scheduler might do, the 
single processor holds latent parallelism in 
abeyance. 

All multiprocessors support some form 
of parallelism, but matching the parallel¬ 
ism of a computation.with that of a target 


architecture is not always simple. The in¬ 
teraction of a multithreaded computation 
with the hardware architecture is not the 
only factor affecting its performance; how 
the computation interacts with the operat¬ 
ing system is also important. 

Figure 12 shows two PIEScope views of 
parts of two matrix multiplier computa¬ 
tions executing simultaneously on a 16- 
processor, shared-bus computer running 
an old version of Mach. The computation 
in the top view began executing first. Our 
interpretation of these views is restricted to 
how the runtime parameters of the compu¬ 
tations affect how much parallelism they 
receive and how the kernel’s scheduler 
reacts to the periods when the two compu¬ 
tations spawn many more threads than 
there are processors available to run them. 

Although our discussion contains some 
fairly detailed analysis, it is not intended as 
an exhaustive critique of the performance 
of the computation and scheduler. Rather, 
we mean it only as another illustration of 
how the behavior of computations and 
schedulers are observable using the PIE 
environment. 

Interpreting the figures. As in the previ¬ 
ous examples, the black rectangles repre¬ 
sent periods when threads are running, 
while white rectangles are periods when 
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Figure 12. Matrix multiplier: first and second computations. 


threads are switched out. Because the 
views depict executions on 16 processors, 
cutting a vertical swath through a view 
may slice through as many as 16 running 
threads. The kernel’s scheduler uses a 
simple, nondiscriminating algorithm with 
the goal of assigning equal time slices to 
competing threads. 

To facilitate the comparison of the 
views, the time stamps of the computations 
are normalized to each other. That is, a 
time stamp of 26.300000 seconds in one 
computation, for example, is simultaneous 
with a time stamp of 26.300000 seconds in 


the other. The time stamps at the beginning 
and end of the PIE views in Figure 12 are 
identical, indicating that the views are 
snapshots of the same period in time. A 
similar pairing of timestamps is done in 
Figures 13 and 14. 

By the time the computations terminate, 
each will have created 34 logical threads 
(main, collector, and 32 multiply threads). 
However, based on considerations such as 
the architecture of the target system and 
the needs of the instrumentation (a collec¬ 
tor thread is needed), invisible PIE runtime 
parameters restrict the number of sched¬ 


uled physical threads each computation 
may have to 17. As we will show shortly, 
the limit of 17 is too small, since the sur¬ 
plus logical threads must wait to execute 
until a physical thread becomes available 
(upon the termination of another logical 
thread, for example). 

The scheduler: Background informa¬ 
tion. Our discussion is restricted to the 
periods when the matrices are actually 
multiplied, since these periods exhibit the 
most interesting behavior. The time cur¬ 
sors in the views in Figure 12 mark the 
approximate moment when the second 
computation commences multiplying its 
matrices. Both views show that, especially 
in the later stages of the computations, 
some threads run without ever being 
switched out. Other threads occasionally 
suffer context-switch flutter, as clearly 
shown by the scattered periods of dense 
“squiggles.” Finally, some are switched 
out for long periods before being allowed 
to run, as in the case of thread number 13 in 
the first computation in Figure 12. 

Unfortunately, a thorough understand¬ 
ing of these phenomena is not possible 
without intimate knowledge of the kernel’s 
scheduling policy and what other threads 
are running on the machine. However, in 
the discussion that follows, we need to 
know only a few underlying characteris¬ 
tics of the kernel. 

First, on this particular kernel one pro¬ 
cessor is designated as a master processor 
on which all thread creation and other 
special work, such as certain disk accesses, 
is done. Second, if all processors are allo¬ 
cated and a new thread is spawned, the 
scheduler may not run the thread right 
away, apparently waiting to see if an exist¬ 
ing thread finishes before adding the new 
thread to the runqueue. Finally, if at any 
time there are more threads than proces¬ 
sors eligible to run, the scheduler will usu¬ 
ally first context-switch threads that have 
been executing for long times. 

By knowing these characteristics as well 
as the approximate number of threads 
vying for processors, we can discern the 
cause of some general phenomena like the 
context-switch thrashing occurring imme¬ 
diately after the time cursor in the top view 
of Figure 12. 

The first computation begins. We begin 
by looking at the period immediately after 
the computation in the top view of Figure 
13 starts spawning its multiply threads. 
Here, for about a second or two, several of 
the threads are executing unencumbered 
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by context switches, while others are either 
switched out (the collector and the number 

13 multiply thread, for example) or switch¬ 
ing repeatedly, as in the case of threads 14 
and 15. The first computation is executing 

14 threads most of this time. 

The bottom view in Figure 13 shows the 
second computation executing only two 
threads — its own main and collector. 
Together, the two computations saturate 
the 16 processors of the computer. How¬ 
ever, as more threads are spawned, it be¬ 
comes more difficult for the scheduler to 
make equitable assignments. 

The top view shows, for example, that 
after thread 13 is forked off, it runs for a 
very brief time (on the master). The sched¬ 
uler immediately deschedules it to run on 
another processor because there is proba¬ 
bly some work queued up for the master. 
Each of the other processors is occupied, 
however, so the scheduler hangs the thread. 
Whether or not the scheduler is doing a 
good job here is a question we will address 
later. 

Returning to the computations, we are 
examining the point immediately after the 
first computation spawns its multipliers, 
when there are roughly 16 threads actively 
vying to run on 16 processors. Shortly, 
however, the scheduler resumes running 
the collector and, later, thread 13 of the 
first computation. Just after the scheduler 
resumes the collector, it iterates through 
the threads, switching one or two out at a 
time, keeping the number of running 
threads at 16. This decision causes more 
Trequent context-switching among the 
other threads, but might be an equitable 
way to assign processors if, for example, 
the threads frequently communicate 
among themselves. Eventually, as Figure 
13 shows, the first computation’s initial 
group of multiply threads finish executing. 

Since the second computation has not 
begun vigorously competing for proces¬ 
sors (it has not yet spawned its multipli¬ 
ers), the scheduler quickly begins assign¬ 
ing a new group of the first computation’s 
multipliers to processors. Although the 
logical threads associated with these new 
multipliers were created about the same 
time as the initial group of multipliers, 
each has been waiting all this time for one 
of the original logical multiply threads to 
relinquish the physical thread it is tied to. 

Here, we see the problem with our lim¬ 
iting each computation to only 17 physical 
threads. Several of the original multipliers 
are parents that cannot relinquish their 
physical threads until their entire lineage 
terminates. Consequently, not many of the 



Figure 13. A closer look at the multipliers: first computation (top); second com¬ 
putation (bottom). 



Figure 14. Selected CPU views of the computation: first computation (top); sec¬ 
ond computation (bottom). 
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Table 1. PIEmacs and PIEScope timings. 


Operation 

Average Rate 

PIEmacs on new program 

300 lines/minute 

PIEmacs on revisited program 

500 lines/minute 

PIEScope reading event file 

3,200 events/minute 

PIEScope reformat + redisplay 

95,000 events/minute 


first computation’s physical threads are re¬ 
linquished and reassigned, limiting the 
parallelism available to subsequent phases 
of the computation. The parents switch out 
at this point, briefly coming in later once or 
twice to join a child or to exit themselves. 
These PIE views led to a modification of 
both the program and the runtime support 
code to permit as much parallelism as the 
machine could provide. 

The second computation comes in. Fig¬ 
ure 13 shows that, shortly after the first 
computation’s new group of multipliers 
begins, the second computation suddenly 
starts spawning its own multipliers (just 
after the first time cursors in the top and 
bottom views) until it reaches the limit of 
17 physical threads. The bottom view 
shows that the scheduler does not immedi¬ 
ately run several of the second 
computation’s threads, preferring to 
switch them out for rather long periods. 
Despite this, there are still more physical 
threads vying to run than there are proces¬ 
sors available to run them. 

At this point, the scheduler begins im¬ 
posing a context-switching toll on the first 
computation, leaving a number of the sec¬ 
ond computation’s threads alone. After a 
while, however, both computations begin 
to thrash quite heavily just after the second 
time cursor in both views in Figure 13. The 
term “thrash” is appropriate because it 
calls to mind the thrashing that occurs in 
virtual memory systems when too many 
users demand too many pages. Such sce¬ 
narios often confound paging algorithms 
and cause them to repeatedly swap pages to 
and from disk. The heavy context switch¬ 
ing occurring here consists of three domi¬ 
nant occurrences: 

(1) switching reminiscent of the “flut¬ 
ter” described in the uniprocessor 
executions, 

(2) interprocessor exchanges of threads 
where two processors simply swap 
the threads they are running, and 


(3) “genuine” descheduling, where a 
thread is switched out for a period of 
time. 

Eventually, after this period of heavy 
competition, the number of threads con¬ 
testing for the processors diminishes and 
the scheduler is able to assign the threads 
without thrashing them. 

Processor utilization. PIE supports a 
supplementary execution view, called the 
cpu-view, that shows processor utilization 
during the execution of a computation. 
Figure 14 shows cpu-views for the first and 
second computations during the same 
block of time shown in Figure 13. As in the 
previous views, time is measured in micro¬ 
seconds on the horizontal, but here the 
machine’s processors are ordered and arbi¬ 
trarily numbered on the vertical. 

Opposite each CPU are alternating sets 
of rectangles. A colored rectangle repre¬ 
sents an identifiable executing thread, 
while a white rectangle is a period when 
none of the respective computation’s 
threads are running on the associated CPU. 

Each view shows the processor utiliza¬ 
tion of only one computation. For example, 
only processor assignments of threads 
belonging to the first computation are 
shown in the top view of Figure 14. PIE 
allows a user to arbitrarily assign unique 
colors to as many threads per cpu-view as 
he or she wishes. 

Being able to assign a unique color to a 
thread allows a user to visually track its 
individual scheduling history. Here, for 
example, the thread represented by the 
bright green rectangles in the top view 
switches from CPU 13 to CPU 24. On CPU 
24, the thread switches to itself a few times 
before moving on to CPU 29 and then 
others as the execution continues. Examin¬ 
ing all the threads in both views, it is 
immediately obvious that, before the sec¬ 
ond computation begins spawning its 
multipliers, the first computation has al¬ 
most exclusive use of the 16 processors on 


the machine. After the spawning, however, 
each view shows only a fraction of the 
processors are allocated to each computa- 


The performance of the scheduler and 
computation. Did the kernel do a “good” 
job scheduling these competing computa¬ 
tions? The answer is probably that it could 
have done better. Did the runtime limita¬ 
tion on physical threads reduce the paral¬ 
lelism available to the computation? It 
seems it did. The first step in improving the 
runtime performance is trivial. How to 
improve to the scheduler’s performance, 
however, is a difficult issue and the subject 
of considerable research. 

It is not always clear what the goals of a 
multiprocessor scheduler should be. 
Should it strive for high performance of 
isolated computations or high processor 
utilization for multiprogramming support? 
In the case of the two simultaneously exe¬ 
cuting computations just discussed, there 
were no special requirements for schedul¬ 
ing them. This was fortunate because the 
kernel had no way of handling special 
scheduling requirements of computations. 

These PIE examples have shown the 
value of visualization in evaluating the 
performance of user-level computations 
and kernel behavior as well. We conclude 
our discussion of performance visualiza¬ 
tion with remarks on some of the issues 
involved in correctly presenting visual 
information. 

Considerations for the 
PIE system 

The experience of designing PIE has 
shaped our ideas on how to detect and 
isolate performance problems in a per¬ 
formance debugging environment. The 
performance of PIE itself is an important 
issue, but equally important is the issue of 
reporting accurate performance informa¬ 
tion. How does collecting performance 
data affect computations and what can be 
done to diminish the effects? Is there a 
preferred methodology for monitoring per¬ 
formance in a visualization environment? 
Is there one best way to use performance 
debugging environments like PIE? Fi¬ 
nally, what environment features do users 
ask for? 

Current PIE performance. Although 
visualizing the performance of user-level 
computations and kernel behavior using 
PIE is a valuable way to understand and 
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debug their performance, PIE itself must 
have acceptable performance if it is to be a 
useful environment. 

Table 1 lists the speeds of some common 
PIE actions performed on a Sun-360 work¬ 
station. The first and second lines show the 
speed of the PIEmacs preprocessor. The 
first time PIEmacs reads a program, its 
structure is stored into PIE’s relational da¬ 
tabase. Subsequent readings of the pro¬ 
gram only have to read the database. Al¬ 
though slow when compared to a typical 
compiler’s parsing rate, the preprocessor 
was developed using the Unix utilities lex 
and yacc. Thus, its performance can be eas¬ 
ily improved in the future. 

The third line is the typical rate at which 
PIEScope reads an event log file. This 
means, for example, that PIEScope reads 
and displays the events for any of the views 
shown in Figure 10 in 15-20 seconds and 
either of the views in Figure 12 in about 50 
seconds. 

However, after PIEScope has read an 
event log file, its display rates are much 
higher. For example, the reformat and 
redisplay rate means that zooming from 
one of the views in Figure 12 to its corre¬ 
sponding view in Figure 13 takes less than 
two seconds. Although this performance is 
acceptable, we are working to improve it. 

Monitor perturbation of a 
computation. Monitoring that signifi¬ 
cantly alters the component execution 
times of a computation and reports only the 
corrupted times back to programmers com¬ 
promises their ability to discern perfor¬ 
mance bottlenecks. When a monitor takes 
time away from a computation — when it 
delays a computation — it perturbs the 
computation. Time penalties are only 
“first-order” perturbations. Lengthening 
the execution times of the individual 
components of a computation might even¬ 
tually distort the order of events and 
change what kind of work the computation 
does. Since monitoring perturbations can¬ 
not be completely eliminated, they must be 
compensated for by measuring them to 
estimate how the computations would 
perform without the perturbations. 

Currently, PIE attempts to compensate 
for perturbation by sensor firings and 
concurrent monitor threads on uniproces¬ 
sors using a fairly simple compensation 
algorithm where the time stamp of each 
event is adjusted in accordance with how 
many monitored events occurred before it. 
The algorithm compensates for each event 
by subtracting from its time stamp the sum 
of all previous sensor firing times plus any 


time consumed by monitor threads like the 
collector. 

The top view in Figure 15, for example, 
shows the tail end of a matrix multiplica¬ 
tion executing on a VAXstation II running 
the New kernel previously shown in Figure 
10. The bottom view shows the same 
computation with the collector and sensor 
times removed after compensation by PIE. 
Although the algorithm is fairly successful 
at predicting the unmonitored execution 
time, there is no guarantee that the compu¬ 
tation would have been scheduled as 
shown in the compensated view. Conse¬ 
quently, PIE is investigating how to gener¬ 
ate compensation confidence values for 
both temporal and behavioral compensa¬ 
tion results. 

Risk of reordering of events using this 
simple compensation algorithm exists, 
especially if it were applied to multiproces¬ 
sor executions. More than just sensor fir¬ 
ing times and collector slices need to be 
taken into consideration before a realistic 
adjustment of the views can be done. Infor¬ 
mation such as synchronization points aris¬ 
ing from thread creation is required if com¬ 
pensation is to be successful. 


In addition to the computation informa¬ 
tion, knowledge is required about monitor 
parameters such as sensor firing times (a 
user-level sensor takes about 500 micro¬ 
seconds), points where the monitor may in¬ 
troduce synchronization overhead, and 
how monitor threads are scheduled with 
the computation. PIE is investigating how 
these and other factors affect compensa¬ 
tion techniques as well as how to detect 
unrecoverable perturbation. 

Performance monitoring scenarios. 

Monitoring scenarios can be divided into 
two broad categories: 

(1) design phase monitoring, where 
designers use performance debug¬ 
ging to sculpt and tune the perform¬ 
ance of computations before de¬ 
ploying them unmonitored, and 

(2) design and deployment phase moni¬ 
toring, where computations are de¬ 
ployed with monitoring hooks in¬ 
cluded. 

If a computation is to be released unmoni¬ 
tored, the most important characteristic of 


October 1989 


49 














































the programming environment is that it 
report the computation’s performance as if 
monitoring perturbation were absent. For a 
computation that is monitored while de¬ 
ployed, it is more important that any per¬ 
formance penalty caused by the monitor is 
acceptable and that the monitor maintain a 
subservient, low-priority role with respect 
to the primary functions of the computa¬ 
tion. 

Monitor priorities. Which is more 
important, the computation’s execution or 
the information about it? This question 
does not have a single answer, for it de¬ 
pends on whether the computation is under 
development or in use. In either case, not 
all information about the computation is 
interesting, and what is interesting infor¬ 
mation may change as the computation 
progresses. 

Measuring the entire computation ... 
When developing a computation, a pro¬ 
grammer wants to ensure that it performs 
correctly and efficiently. During the devel¬ 
opment stages, it is important that very 
little performance data, if any, is lost by the 
monitor. A programmer examining the 
synchronization behavior of a computa¬ 
tion would be ill served if a monitor lost 
events when synchronization occurred. 
Environments must guarantee that every 
selected event is recorded even if suspend¬ 
ing it is occasionally necessary; otherwise, 
the ability of programmers to discern what 
their computations really do is compro¬ 
mised. 

... versus maintaining a performance 
level. Perturbation of a monitor that is part 
of both the design and deployment phases 
of a computation is no longer perturbation 
per se, but merely part of the overall behav¬ 
ior of the computation. The real behavior 
of the computation is that of both the moni¬ 
tor and the primary functions of the rest of 
the computation. What is important in such 
cases is not monitoring perturbation but 
monitoring performance. In such cases, 
the most important requirement of a moni¬ 
tor is that it never suspends a computation. 
It would be highly undesirable, for ex¬ 
ample, if a monitor used in an air-flight 
control application stopped the computa¬ 
tion to “catch up” on recording events. No 
matter how unappetizing losing events 
may be, it is more important that the com¬ 
putation continue unperturbed. 

User control of the environment: Han¬ 
dling changing demands. Programmers 


often begin measuring a computation’s 
performance by monitoring its high-level 
behavior. As an environment like PIE 
reports what the computation is doing, the 
programmer might decide to direct atten¬ 
tion to more detailed behavior. For short 
computations, this step-by-step analysis 
may be spread over several successive 
executions, each one monitored differ¬ 
ently. This is impractical for continuously 
executing computations (industrial control 
programs, for example) or those that re¬ 
quire such a long time to execute that the 
turnaround time until the next observable 
execution is unacceptable. 

Interactive runtime capabilities. Envi¬ 
ronments with interactive runtime capa¬ 
bilities would allow programmers to pe¬ 
ruse the execution of computations, mov¬ 
ing their attention to different parts or 
asking for greater detail as the computa¬ 
tions proceed through the different stages 
of their execution. Before an environment 
can adapt to the runtime vicissitudes of a 
programmer, it must have an interactive 
interface. 

More ambitious environments might 
support dynamic changes to the object 
code of a computation while it executes so 
the programmer can conveniently test 
coding changes during runtime instead of 
resorting to time-consuming recompila¬ 
tion. 13 The PIE environment allows pro¬ 
grammers to observe computations while 
they execute, but has only limited interac¬ 
tive features. These capabilities are being 
extended to support more versatile interac¬ 
tion. 

Tailoring a monitor to a computation. 
When computations are monitored after 
having been deployed, programmers are 
interested in adjusting monitoring charac¬ 
teristics to improve the performance of the 
entire computation. However, because a 
monitor is supplied by the programming 
environment, programmers can not mod¬ 
ify it as freely as they would a computation 
without risking the integrity of the moni¬ 
toring code. 

To assist programmers in improving 
monitoring performance, environments 
like PIE should provide means for design¬ 
ers to tailor the characteristics of the 
monitor to meet the performance require¬ 
ments of their computations. However, the 
environment must restrict the kinds of 
changes permitted to ensure that program¬ 
mers cannot introduce bugs into the moni¬ 
tor. Currently, PIE permits a programmer 
to modify only a few selected monitoring 


parameters. As part of the effort to improve 
the interactive nature of PIE, more options 
are promised for customizing monitoring. 


V isualizing the behavior of compu¬ 
tations, as in PIE, is a suitable 
way to study and improve their 
performance. Although PIE is a success¬ 
ful, useful research effort, it is not limited 
to merely improving computations. It is 
also a valuable educational tool for under¬ 
standing the complexities of both sequen¬ 
tial and parallel programming. It helps to 
remove the veil of mystery surrounding the 
execution of computations on complex 
systems. Even the scheduling behavior of 
an operating system, a seemingly esoteric 
activity over which the programmer fre¬ 
quently has no control, is revealed simply 
and elegantly in PIE. 

The immediate research plans for PIE 
include the design and implementation of a 
performance degradation prevention advi¬ 
sor and procedures for automatic tech¬ 
niques for performance degradation avoid¬ 
ance. As we complete this work and ad¬ 
dress the issues described earlier, the per¬ 
formance visualization PIE offers will 
remove additional shrouds of complexity 
from sequential and parallel computations 
and the systems that run them. □ 
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VISUALIZATION IN COMPUTING 


Graphical Configuration 
Programming 

The structural description, construction and evolution 
of software systems using graphics 


Jeff Kramer, Jeff Magee, and Keng Ng 
Imperial College of Science and Technology 


S oftware systems can be succinctly 
described, constructed, and man¬ 
aged in terms of their software con¬ 
figuration. 1 ' 4 This configuration consists 
of the set of software components that 
implement system functionality, plus their 
control and communication interconnec¬ 
tions. Program modules are defined and 
constructed to provide well-defined inter¬ 
faces, giving the information and calls 
provided to or required from other mod¬ 
ules. The program is then configured by 
creating and interconnecting instances of 
these software modules. 

The specification of the system configu¬ 
ration provides a conveniently abstract 
form in which to define and comprehend 
programs, and it can also be used to gener¬ 
ate the executable program. Evolutionary 
changes to the program are reflected as 
changes to the program structure, either by 
the addition of further modules or by the 
use of modified versions of selected mod¬ 
ules. “Configuration programming,” the 
term we use to describe programming at 
the configuration level, thus provides a 
clear and flexible means for program defi¬ 
nition, construction, modification, and 
comprehension. Configuration program- 


This workstation 
integrates the textual 
and graphical 
information required for 
configuration 
programming. Its 
editing, monitoring, 
layout, and control 
facilities are applied 
dynamically to 
operational systems. 


ming is closely related to the ideas of 
programming-in-the-large and the use of a 
module interconnection language outlined 
by DeRemer and Kron. 1 Configuration 


refers here to system structure, not to ver¬ 
sion control. 

Configuration programming is particu¬ 
larly appropriate for distributed process¬ 
ing, where the software components may 
reside on different machines. The configu¬ 
ration specification can both describe the 
structure of the required system and spec¬ 
ify the allocation of components to ma¬ 
chines. The operational system is then 
managed by monitoring the status of sys¬ 
tem components and extending or chang¬ 
ing the system configuration. Such 
changes may involve modifying existing 
functions or introducing new functions to 
incorporate new technology, improve 
implementation techniques, or provide 
system redundancy. It is certainly advanta¬ 
geous for configuration management to 
dynamically support change to the system 
without interrupting processing elsewhere 
on the system. 

The Conic environment, 5 developed by 
the Distributed Systems Group at Imperial 
College, supports configuration program¬ 
ming for distributed and concurrent pro¬ 
grams. The environment supports two 
languages, one for programming individ¬ 
ual task modules (processes) with well- 
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group module patient; 

use monmsg: bedtype, alarmstype; 
exitport alarm:alarmstype; 
entryport bed:signaltype reply bedtype; 

{ 

- The module periodically reads sensors attached to a patient. 
Readings outside preset ranges cause alarm messages to be 
sent to the exitport alarm. 

A request message received on the entryport bed returns the 
current readings and ranges. 

1 





alarm 1 J 

r 1 

> bedl 

alarm2 J 

1 nurse ^ 

, bed2 

alarm3 J 

1 1 

_ bed3 

alarm4 J 

1 & 

> bed4 

alarms J 

r 1 

> bed5 

group module nurse (maxbed:integer=5); 
use monmsg: bedtype, alarmstype; 
entryport alarm[ 1 ..maxbed]:alarmstype; 
exitport bed[l..maxbed]:signaltype reply bedtype; 

- the module displays alarms received from alarm[ ] 
and can request the display for a particular patient from 
its exitports bed[ ]. 

J 

end 




Figure 2. The nurse module. 


Figure 1. The patient module. 


defined interfaces and one for configuring 
programs from groups of task modules. In 
addition, the environment supports mod¬ 
ule reuse and was recently extended to 
support dynamic configuration. The latter 
facility is achieved with on-line manage¬ 
ment tools that permit dynamic creation, 
control, and modification of application 


programs. The basic Conic environment 
has been in use for more than five years and 
has amply demonstrated the utility of 
configuration-level programming. 

Although configurations are most easily 
described and viewed graphically, 3 ' 4 they 
have traditionally been provided to the 
support environment in textual form. 


which is more concise and easier to parse. 
For example, Conic’s developers and users 
have always drawn diagrams to describe 
and document their configurations, while 
their interactions with compilers, builders, 
and managers have always been textual. 
This disparity, plus the availability of 
graphics-based workstations, prompted us 
to develop graphical support for configu¬ 
ration programming — essentially, a vis¬ 
ual programming language for configura¬ 
tion. However, in contrast to most work on 
visual programming, 6 our approach em¬ 
phasizes system structure in-the-large 
rather than detailed data and control struc¬ 
ture. The combination of graphics and text 
is a powerful facility; the graphics comple¬ 
ments the text by reflecting the described 
or existing configuration, thereby aiding 
comprehension and validation. Of course, 
the text is still essential for detailed infor¬ 
mation and for certain complex cases not 
amenable to display. 

Configuration 
programming in Conic 

The configuration programming con¬ 
cepts embodied in Conic are illustrated by 
a simple example: a patient monitoring 
system. 7 The intensive care ward in a hos¬ 
pital consists of a number of beds. Patients 
in each bed are continuously monitored for 
a number of factors, such as pulse, tem¬ 
perature, and blood pressure. Current fac¬ 
tor readings are displayed both at the bed¬ 
side and at the nurse unit. If any of a 
patient’s readings are outside preset limits, 
an alarm is sent to the central nurse station. 

Module types. The system is con¬ 
structed from the two module types de¬ 
fined both graphically and textually in 
Figures 1 and 2. 

Typed exit and entry ports define the 
module interface. Messages of any Pascal 
data type are sent out via exit ports and 
received from entry ports. The type defini¬ 
tions are imported from definition units by 
the use clause (types bedtype, alarmstype 
from monmsg in Figures 1 and 2). 

System configuration. Given the hard¬ 
ware depicted in Figure 3, we can construct 
an initial patient monitoring system con¬ 
sisting of one nurse unit and one patient 
unit by instantiating one instance of each 
of the above module types and intercon¬ 
necting their exit and entry ports. The links 
between exit and entry ports allow mod- 
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ules to communicate by message passing. 
Conic permits connecting only ports of the 
same type. The configuration program for 
this system is shown both textually and 
graphically in Figure 4. 

We actually create the system by sub¬ 
mitting the configuration description to a 
configuration manager tool that either 
downloads module code into target proces¬ 
sors or instantiates processes under Unix 
as appropriate. 5 The description can be 
submitted directly as text or indirectly 
using the graphical editor. As shown in 
Figure 4, the graphical description con¬ 
tains less information than the textual one; 
the graphics tool elicits additional infor¬ 
mation through dialog boxes. This extra 
information consists of the physical mod¬ 
ule location (the at clause) and module 
parameters. For example, the nurse mod¬ 
ule has a default parameter setting to the 
value 5 (Figure 2). However, this could 
have been changed when the module in¬ 
stance was specified, that is, 

create nurse:nurse(3) at sunl. 

Dynamic configuration. In addition to 
programming initial configurations, the 
Conic toolkit permits dynamic configura¬ 
tion: changes to running systems. For 
example, we can extend the above system 
to include an additional patient unit by 
submitting the following configuration 
program to a configuration manager: 

manage ward; 
create 

bed2: patient at targ2; 

link 

bed2.alarm to nurse.alarm[2]; 

nurse.bed[2] to bed2.bed; 

end 




The ward system (Figure 4) evolves dy¬ 
namically to the system in Figure 5. 

In practice, we have found it convenient 
to create initial systems from the more- 
concise configuration program. Once cre¬ 
ated, the graphics tool can display the 
system as it exists: It gathers information 
directly from the executing system by 
communicating with a configuration man¬ 
ager and can query textual information not 
directly displayed. We can then modify the 
system through either graphical com¬ 
mands or configuration program text. 
Also, a change performed graphically can 
be saved in text form for later reuse. 

The configuration management system 
is itself a distributed system, so more than 
one agent can change the system configu- 



Figure 5. Extended patient monitoring system. 
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group module patient; 

use monmsg: bedtype, alarmstype; {import message types) 

exitport alarm:alarmstype; 

entryport bed:signaltype reply bedtype; 

use scanner; monitor; {import module types) 

create 

scanner(lOO); {scan every 100ms) 
monitor; 

link 

scanner.readings to monitor.readings; 
monitor.alarm to alarm; 
bed to monitor.data; 


Figure 6. Internal structure of patient module. 


The module types used to construct the 
patient module can also have an internal 
structure. A Conic system is thus a hier¬ 
archic structure of modules. The modules 
at the bottom are task modules imple¬ 
mented in a version of Pascal to which 
message-passing constructs have been 
added. These task modules execute con¬ 
currently and are hierarchically structured, 
using the configuration programming lan¬ 
guage, into logical nodes. Logical nodes, 
which are simply module groups that in¬ 
clude a runtime executive, are the unit of 
both distribution and dynamic configura¬ 
tion. The structure of modules within a 
logical node is determined at compile time 
and does not change at system runtime. 
Consequently, the graphics tool does not 
need to edit internal node structure. How¬ 
ever, we intend to provide the ability to 
“explode” logical nodes to allow examina¬ 
tion of their internal structure and aid sys¬ 
tem comprehension. This, with the ability 
to examine a module’s program text 
(whether a configuration program or a task 
program), will provide a powerful system¬ 
browsing facility. 


ration. Used in a monitoring mode, the 
graphics tool allows users an up-to-date 
view of the system configuration. For 
example, the diagram in Figure 4 was cre¬ 
ated by using the graphics tool to monitor 
a system created from that figure’s con¬ 
figuration program. The system was ex¬ 
tended by editing the diagram directly to 
create Figure 5. These edits caused the tool 
to send the extension configuration text to 


a configuration manager, which changed 
the actual system accordingly. 

Module hierarchies. We have de¬ 
scribed the top-level configuration of 
modules to construct a patient monitoring 
system. In fact, the two module types used 
are themselves module configurations. 
See, for example, the internal structure of 
the patient module in Figure 6. 



Figure 7. Relationship between ConicDraw and system. 


The ConicDraw 
graphical workstation 

As mentioned above, diagrams have 
always been used with Conic’s textual 
descriptions and commands, although 
their use was originally informal and they 
were generated manually. Now, text and 
diagram facilities are integrated, and 
graphics are provided by the ConicDraw 
graphical workstation. 

As shown in Figure 7, the management 
system provides both an interactive textual 
and graphic interface to the operational 
system. ConicDraw maintains a graphic 
representation of executing Conic systems 
in terms of their module instances, inter¬ 
connections, and execution state. Changes 
are reported by configuration manage¬ 
ment, so ConicDraw can maintain up-to- 
date views of the systems. ConicDraw can 
also instigate changes as a result of edits to 
the graphic representation. Since it always 
maintains a representation of the actual 
system, one or more workstations can be 
connected tothedistributedsystem, thereby 
allowing a number of users to manage and 
monitor the system cooperatively. 
ConicDraw contains a comprehensive set 
of tools for creating and editing Conic 
configuration diagrams. As such, it can also 
be used as a stand-alone diagram editor. 
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Figure 8. Icons in the systems window. 



We chose an Apple Macintosh as the 
implementation hardware because of its 
comprehensive support for graphic-inter¬ 
face programming and because we had 
experience with it from a previous project. 
The Macintosh communicates via a serial 
RS-232 communication link with the dis¬ 
tributed system (running on Sun, VAX, 
and VME 68000 machines connected by 
Ethernet). This serial link limits response 
times and may be replaced by a direct 
Macintosh-to-Ethernet connection. 

In the following sections, we describe 
ConicDraw’s main facilities and discuss 
issues raised by its implementation. 

System monitoring. To support the on¬ 
line monitoring of systems, ConicDraw 
needs access to the executing distributed 
system. This is achieved by running a 
special version of a configuration manager 
(gman) with ConicDraw (Figure 7). Gman 
is a Conic program running on a host 
machine and communicates with 
ConicDraw on the Macintosh via a serial 
link. In the same way that an interactive 
manager (iman) supports the textual inter¬ 
face, gman acts as a server to ConicDraw 
and can provide information about all 
Conic systems running on Unix machines 
as well as stand-alone targets. Using a 
simple communication protocol, gman 
supplies ConicDraw, on request from the 
latter, the names of currently active sys¬ 
tems and the nodes, ports, and interconnec¬ 
tions within each system. In addition, it can 
provide detailed information about each 
node, such as the type of node, which 
machine it is running on, and how long it 
has been running. 

At the beginning of a session, the user 
typically wants to find out what systems 
are running in the network. Selecting “Get 
systems” from the Command menu puts a 
set of icons in the Systems window, as 
shown in Figure 8. Each icon represents 
one Conic system and acts as the interface 
for accessing the system. To view a sys¬ 
tem, the user need only double-click on the 
appropriate system icon. This opens the 
system to reveal its internal nodes and their 
interconnections. The pictorial representa¬ 
tion of the system is displayed in a graphi¬ 
cal window (Figure 9). 

ConicDraw allows multiple systems to 
be open at the same time. The number is 
limited only by the computer’s memory. 
By default, ConicDraw will continuously 
poll an open system for changes to either 
its structure or its state. When a change is 
detected, the system’s diagram is appropri¬ 
ately updated to ensure that the graphical 


information is consistent with the system’s 
true state. 

When several systems are open, the user 
can monitor all of them or just the one that 
is frontmost on the screen. Monitoring can 
also be turned off completely, in which 
case none of the system diagrams are 
updated. In addition, the user can modify 
polling frequency, depending on how rap¬ 
idly the system is expected to change. All 
these monitoring options are set via a dia¬ 
log box (Figure 10). 

Nodes in a diagram can be displayed in 
several ways. The default is to view nodes 
by their names; that is, only the instance 
name is displayed in its box. Other options 
are viewing by type, location, or full infor¬ 
mation, in which case the information dis¬ 
played includes the name, type, location, 
and state of the node, as well as its environ¬ 
ment (whether it is running on a Unix 
machine or a stand-alone target). A user 
can also find out how long a node has been 
running by choosing the “Get info” menu 


command. This opens a dialog box that 
displays the node’s full information, plus 
its uptime (Figure 11). 

Because messages received from gman 
contain no layout information, ConicDraw 
is responsible for placing system compo¬ 
nents in a diagram. We presently use a 
simple layout strategy, rather than a com- 



Figure 10. Options for system moni¬ 
toring. 


October 1989 


57 


























































Node : 

6220 



Type 

gman 

Enuiron 

uniH 

Status 

Stopped 

Machine 

68000 

Location 

chico 

Uptime 

1:20:10 

[ ™ 1 



[ CanceT] 


Figure 11. Detailed information of a node instance. 
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Figure 12. Creation of a new node instance. 
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plex algorithm, to minimize the delay be¬ 
tween a user’s request for the system and 
the display of its diagram. This simple 
strategy is also important in reflecting 
systdm changes as they happen. 

Initially, nodes are placed into arrays of 
grid cells and the ports are scattered ran¬ 
domly along the four faces of their parent 
nodes. Links are then drawn as single¬ 
segment straight lines connecting the ap¬ 
propriate message ports. The resulting 
diagram is invariably messy and often 
unreadable, so we have introduced a tidy- 
up facility based on some simple heuris¬ 
tics. It is invoked after each system request 
(and change) to clean up a diagram. 

Dynamic configuration. Once a system 
diagram is displayed, it is subject to user 
modifications. These can be either cos¬ 
metic modifications to the layout or struc¬ 
tural changes to system components or 
their status. Users effect both types of 
changes by directly manipulating graphi¬ 
cal objects on the screen. ConicDraw treats 
structural changes as commands and relays 
them to gman, which makes the equivalent 
changes to the running system. These 
changes include creating and deleting 
nodes, linking and unlinking of exit and 
entry ports, and changes in node status. 

To add a node, the user selects the node 
tool from the tool palette and draws a 
rectangle in the system window. This 
brings up a dialog box that prompts the 
user for the name, type, and location of the 
new node instance, as well as any extra 
parameters needed for its creation (Figure 
12). This information is then packaged and 
sent to gman as a “create” command. 

To create a connection between an exit 
and entry port, the user simply draws a link 
between the two ports. This link can be a 
single straight line or a multisegment 


polyline. The result is a “link” command 
sent to gman with the appropriate argu¬ 
ments. To delete a node or a link, the user 
selects the item with the selection tool and 
then chooses the “Clear” item from the 
Edit menu. 

The creation or deletion of a node or a 
link can fail for various reasons. In these 
situations, the displayed system configura¬ 
tion will be inconsistent with the system’s 
true state. To overcome this problem, we 
introduced the “zombie” state, an interme¬ 
diate state acquired by an object in the 
process of being created or deleted. A 
zombie object will remain in this state until 
gman confirms its creation or deletion. 
ConicDraw represents a zombie node by a 
rectangle filled with an irregular pattern 
and a zombie link by a dashed line. 

A user changes node status via the “Start 
nodes” and “Stop nodes” menu commands. 
To start a node, the user selects it with the 
selection tool and then chooses “Start 
nodes” from the Command menu. Since 
this command works on any node selected, 
multiple nodes can be started at the same 
time. The “Stop nodes” command works in 
a similar way. The status of a node relates 
to its configuration management state as 
determined by a change management 
protocol. 8 

For an example of how ConicDraw per¬ 
forms and controls dynamic system con¬ 
figuration, see the accompanying sidebar. 

Diagram layout support. ConicDraw 
provides all the standard editing facilities 
expected of a diagram editor. It lets users 
move and resize nodes, drag ports to any 
node face, and reshape links by adding or 
deleting individual segments in the link. In 
addition, it knows the syntax of Conic 
configuration diagrams and can therefore 
prevent construction of syntactically ill- 


formed diagrams. For example, it ensures 
that all of a node’s ports and links stay 
connected when the node is moved and that 
a port cannot be detached from its parent 
node. Because ConicDraw also maintains 
information on port types, it further en¬ 
sures that only compatible entry and exit 
ports are connected. 

A graphical system must give the user 
full control over the layout of his diagram. 
It is equally important, however, that the 
tool simplifies the task of editing and 
maintaining the diagram. This is especially 
true for ConicDraw. Since the tool auto¬ 
matically generates a system configura¬ 
tion diagram from information derived 
directly from the operational system, the 
diagram often requires considerable edit¬ 
ing before it resembles the structure the 
user had in mind. We provide various fa¬ 
cilities to automate some frequently per¬ 
formed editing tasks, as well as tools to 
help the user manage complex diagrams. 
However, rather than force these tools on 
the user, we provide them as options for 
more flexibility. 

Automatic diagram tidy-up. This facil¬ 
ity, invoked automatically after a system 
diagram is generated, is also available 
manually by choosing the “Tidy diagram” 
item in the Layout menu. The algorithm 
uses two criteria in improving a diagram 
layout: minimize the lengths of links, and 
minimize crossovers between links. These 
criteria are met by performing the follow¬ 
ing steps: 

• Determine on which node face a port 
should be placed. This step involves going 
through all the links in the diagram and 
pulling together the ports at either end, as 

(Continued on p. 62) 
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A Demonstration of Dynamic Configuration 

To illustrate how ConicDraw dynamically reconfigures systems, we use the patient monitoring system described in the section 
titled “Configuration programming in Conic.” The example outlines the steps required to display the system configuration, shows 
how a new patient can be added and linked into the system, and shows how to obtain detailed information about nodes via the 
graphical interface. 


ConicDraw starts by displaying two blank windows: Systems 
and Terminal. The Systems window displays the system icons. 
The Terminal window functions as a terminal emulator, allowing 
the user to start up gman on the host machine. 

To manage a system, first choose “Get systems" from the 
Command menu. This sends a systems command to gman. 


Gman returns the names of all running systems and displays 
them as icons in the Systems window. 

To display the state of the patient monitoring system named 
ward, double-click on its icon in the Systems window. 


' 


This action brings up a graphical window called ward, which 
displays the current state of the system. 

The system consists of three nodes: a nurse and two patients, 
bedl and bed2. All three nodes are painted white, indicating 
that they are in the stopped state. 

Note that the system diagram shown here is generated by 
ConicDraw based on the heuristics outlined in the section titled 
“The ConicDraw graphical workstation.” 
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This figure shows the system diagram after it has been manu¬ 
ally tidied up. 

To create a new patient node, select the node tool in the tool 
palette and draw a rectangle in the window. 


This action brings up a dialog box that prompts the user for 
the information needed to create the node. Fill in the text areas 
as shown and click the OK button. This is equivalent to entering 
the textual command: create bed3 patient at Sunl. 

The parameters field was left blank, since the patient module 
does not require any extra parameters. 


As shown in the Terminal window, the create command is 
sent to gman. At the same time, the node created is filled with 
an irregular pattern to indicate its “zombie” status. 


Gman confirms the creation of this node when the system is 
next polled. ConicDraw then sets the node’s status to stopped 
and shows its entry and exit ports. 
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To connect bed3 to nurse, select the link tool in the tool pal¬ 
ette and draw a link from the exit port labeled bed3 to the entry 
port labeled bed. Draw another link from alarm to alarm3. This 
is equivalent to issuing the commands: 

• link nurse.bed3 to bed3.bed 

• link bed3.alarm to nurse.alarm3 


All the nodes in the system are still in the stopped state. To 
start the nodes, select them with the selection tool and then 
choose “Start node” from the Command menu. 


A start command is sent to gman for each of the selected 
nodes. Once started, the nodes are painted gray to indicate 
their new state. 


' 


To get detailed information on the nurse, select it with the 
selection tool and then choose “Get info...” from the Command 
menu. This brings up the dialog box as shown in the diagram. 
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rithms might not be acceptable to every- 


Figure 13. Minimizing the length of a link. 



Figure 14. Avoiding crossovers between links. 



Figure 15. A dining philosophers system before and after tidy-up. 



(Continued from p. 58) 

illustrated in Figure 13. As a result, the 
ports at the ends of a link will be on the 
opposite faces of their nodes. Whether they 
end up on the north-south or east-west 
faces depends on which pair produces the 
shorter link. At the end of this step, all the 
ports in the diagram will have been posi¬ 
tioned on the adjacent faces. 

• Determine the relative positions of 
ports on a face. This step involves finding 
out, for each node, the relative positions of 
other nodes to which it is connected. This 
information is then used to sort the ports so 
that their links do not cross. In addition, the 
ports on each face are spread evenly along 
the face to obtain a regular appearance. 
Figure 14 shows an example of the effects 
of this step. 


In practice, the above algorithm may not 
be sophisticated enough to produce an 
aesthetically pleasing layout. But it is a 
very fast, effective way of generating a 
fairly clean diagram that can be enhanced 
through manual editing. It produces par¬ 
ticularly good results if the user places the 
nodes in roughly the right locations before 
invoking the command (see Figure 15). 

Templates. The automatic tidy-up facil¬ 
ity cleans up the links but makes no attempt 
to reposition the nodes. Various placement 
algorithms exist for diagram layout and 
VLSI design, but the programs tend to be 
large and to execute slowly, making them 
unsuitable for an interactive tool such as 
ConicDraw. Furthermore, the aesthetics of 
diagrams is a subjective matter, so the re¬ 
sults produced by even the best of algo- 


Templates offer an effective way of 
overcoming this problem by enlisting the 
user’s help. This is an idea borrowed from 
desktop publishing, where the page de¬ 
signer often describes a page layout in 
terms of blocks or columns of text and 
pictures. This forms a template that deter¬ 
mines the appearance of the page. These 
blocks of text and pictures act as place 
holders for the contents of the page and are 
independent of content. This independ¬ 
ence means that the page layout informa¬ 
tion can be stored separately and reused. 

ConicDraw uses a template to determine 
node placement. Associated with each 
diagram is a template that can contain 
multiple node holders. To create a holder, 
the user switches to the template view by 
choosing the “Switch view” menu com¬ 
mand. This gives him a new set of tools for 
creating the different types of holders. 
There are three types of general node hold¬ 
ers: ring, row, and column. The user asso¬ 
ciates a holder with a node by giving each 
holder a holder type. Any node of that type 
then belongs to that holder. Figures 16 and 
17 show the patient monitoring system 
with all the patient nodes placed in a col¬ 
umn holder and a ring holder, respectively. 

ConicDraw distributes nodes evenly in 
each holder. The user can change the rela¬ 
tive positions of the nodes by dragging 
them with the selection tool. The user does 
not have to do this precisely because the 
nodes will, by default, snap back to their 
holder and redistribute automatically. 
Similarly, when a holder is moved or re¬ 
sized, all its nodes will relocate appropri¬ 
ately. 

When combined with the tidy-up facil¬ 
ity, templates are an effective layout aid. 
We’ve found them particularly useful for 
diagrams with regular layouts, such as 
those depicting client-server models. On 
the other hand, these template facilities are 
fairly restrictive; possible extensions 
would allow nodes of more than one type 
in a holder, nodes of the same type in more 
than one holder, groupings of holders, and 
new types of holders. 

Alignment grid. To help the user line up 
nodes precisely, ConicDraw has an invis¬ 
ible alignment grid that constrains node 
placement. When a node is created or 
subsequently moved, its top-left comer 
automatically snaps to the nearest point in 
the grid. This feature can, however, be 
turned off by the user who wants finer 
control over the layout. 
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Figure 16. Patient nodes arranged in a column holder. 



Automatic line-straightening. When a 
user draws or moves a link that has more 
than one segment, each segment is auto¬ 
matically checked and, if necessary, modi¬ 
fied so that it lies in either a horizontal or 
vertical direction. Thus, if the user wants 
only horizontal and vertical links in his 
diagram, he can draw lines approximating 
the desired shape and let the tool do the 
necessary modification. 

Hiding port names. Screen cluttering is 
a common problem for complex diagrams, 
especially given the small size of the stan¬ 
dard Macintosh screen. We therefore give 
the user the option of not displaying the 
names of the entry and exit ports. This 
usually improves diagram readability and 
is especially useful when the user is pri¬ 
marily interested in diagram structure. 

Diagram scaling. ConicDraw allows 
diagram viewing and editing at any level of 
magnification. The user can zoom in on a 
particular portion of a diagram for detailed 
editing or zoom out for a complete view of 
a complex diagram. The Layout menu 
provides five items for controlling the 
scaling of diagrams. The first four enable 
fast switching to four preset scales: size to 
fit, 50 percent, 75 percent, and normal size. 
The fifth item lets the user specify the 
scaling factor via a dialog box. 

Browsing and 
animation extensions 

Based on experience using ConicDraw, 
we plan to expand its capabilities in system 
browsing and animation. 

System browsing. The nodes displayed 
graphically by ConicDraw have an internal 
structure. We plan to include a facility to 
“explode” nodes so that their internal 
structure can also be viewed graphically. A 
user will be able to trace down through the 
hierarchy of modules that constitute a 
system until, at the bottom level, he or she 
can view task module program text. Based 
on our experience with the tool at the 
dynamic configuration level, we believe 
system browsing will be a powerful aid to 
understanding complex systems. The ap¬ 
proach we have adopted has more in com¬ 
mon with design-and-specification tools 9 
than with more-conventional browsers 
such as those in Smalltalk-80. At each 
level, the user will be able to view both the 
configuration program text and its graphi¬ 
cal representation (as is currently provided 
at the top level). 


We believe strongly in the importance of 
retaining a textual representation of the 
configuration, since in some instances it 
conveys a clearer understanding of a 
module’s semantics. The examples pre¬ 
sented earlier used a subset of the configu¬ 
ration language’s facilities; consequently, 
the graphical representation was adequate. 
The following example forms part of a 
parallel implementation of the fast Fourier 
transform. It uses imported functions to 
control the internal connection pattern. 
Inputs are connected to the output that has 
a bit-reversed value of their input index. 

group module interleave(n:integer); 
use 

funcs:backwards,log2; 

compv:complex; 

entry port 

input[0. ,n-1 ] xomplex; 

exitport 

output[0..n-1 ] xomplex; 
link family k:[0..n-l] 

input [k] to 

output[backwards(k,log2(n))]; 

end 

For large values of n, this module’s 
graphic representation appears as if inputs 
were connected to outputs at random. The 


text conveys the structure’s purpose more 
clearly. Similar problems occur when re¬ 
cursion is used in the configuration pro¬ 
gram. 

Animation. One problem in using 
ConicDraw is the speed at which system 
changes can occur. Usually, these rapid 
changes result from the configuration 
manager’s execution of preprogrammed 
reconfigurations in response to failures or 
to user action. Configuration programs are 
essentially declarative. The configuration 
management system uses a nontrivial algo¬ 
rithm to order the execution of individual 
configuration actions. Viewing these 
changes in real time (or as fast as 
ConicDraw can display them) conveys 
little to the user of the sequence of actions 
effecting the change. Consequently, we 
intend to provide a facility to record the 
sequence of changes and replay them gra¬ 
phically at a speed comprehensible to the 
user. This facility can be thought of as 
animating the execution of changes. Such 
animation can be used to test configura¬ 
tion-change programs before using them 
on the actual system. Earlier work in re¬ 
quirements analysis 10 has demonstrated 
the value of animation. 
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C onfiguration programming pro¬ 
vides a clear and flexible means for 
program definition, construction, 
and management. Its advantages have 
been recognized for both conventional 
software development, as in the use of 
interface specifications in the Inscape en¬ 
vironment, 11 and in distributed systems 
such as Conic and, more recently, Durra. 12 
Graphical support is particularly appropri¬ 
ate for the structural information used in 
configuration specifications. Stile 13 also 
applies graphics to configuration, but it fo¬ 
cuses on design and development rather 
than system construction and management. 

Our experience shows that ConicDraw 
is a powerful aid to understanding and 
constructing configuration programs. 
While textual programs have the advan¬ 
tage of conciseness and clarity in express¬ 
ing complex structures, graphics offer a 
more accessible human interface. The abil¬ 
ity to translate between the two forms of¬ 
fers the best of both worlds. □ 
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Information technology standards: What determines success? 

Helen M. Wood, National Oceanic and Atmospheric Administration, and President-elect, IEEE Computer Society 


Increasingly, researchers, administra¬ 
tors, service providers, and organiza¬ 
tions depend on the availability of com¬ 
puter-based systems and data in elec¬ 
tronic form to do their work. The United 
States government alone spends nearly 
$20 billion a year to acquire, maintain, 
and operate information technology to 
improve efficiency and effectiveness. 

The enormous investment in electronic 
databases motivates organizations to 
seek ways to preserve their investments 
in data and applications software when 
systems are replaced. Where circum¬ 
stances preclude co-location of related 
data collections, remote access to distrib¬ 
uted, possibly dissimilar databases is of¬ 
ten required. These are just a couple of 
examples of the forces that have created 
today’s high levels of interest in informa¬ 
tion technology standards. 

Standards are developed in response to 
a common, recurring problem. They can 
be developed through a consensus pro¬ 
cess involving those whose interests will 
be affected by a given standard or can be 
established by regulation or law. Regard¬ 
less of their original motivation (for in¬ 
stance, improved interoperability, relia¬ 
bility, quality, ease of use), standards 
may have a significant impact on domes¬ 
tic commerce and international trade. 

Standardization activities. Although 
few noticed or cared at the time, formal 
standardization activities in information 
technology began a quarter of a century 
ago. One of the first successful standards 
defined the binary composition (codes) 
for a standard set of characters. This stan¬ 
dard, ASCII (for American Standard 
Code for Information Interchange), was 
developed to facilitate the exchange of 
data between computer systems made by 
different manufacturers. The US govern¬ 
ment adopted ASCII as the first Federal 
Information Processing Standard (FIPS). 

Over the years, ASCII has been joined 
by thousands of other standards address¬ 
ing every facet of information pro¬ 
cessing. Only a relatively small number 


of these standards has achieved wide¬ 
spread recognition. Since the develop¬ 
ment of a standard typically takes three to 
five years, participants and those who 
pay the expenses the process requires 
should carefully choose the activities in 
which they become involved. 

A number of factors determine the po¬ 
tential for success or failure of a particu¬ 
lar standard. These include 

• the aspect or type of standard, 

• the expected benefits and costs of the 
standard, and 

• the level of standardization. 

Aspect of standardization. For a given 
subject (for example, electricity, com¬ 
puter hardware, software), there may be a 
number of different types or forms of 
standards. Examples include 

• definitions of terms for that field, 

• specifications of the quality or per¬ 
formance of a material or machine, 

• methods of sampling or inspection, 

• methods of grading for products 
(such as timber, eggs), 

• packaging or labeling, 

• conformance test methods, and 

• codes of practice. 

There may be other types or aspects of 
standardization besides those listed 
above. Further, not all aspects may be 
standardized for a particular subject. De¬ 
termination of the areas to be standard¬ 
ized is largely determined by still other 
factors. 

Benefits/costs of standards. Today, 
both vendors and users are promoting 
standards for “open” systems. These 
standards are intended to allow comput¬ 
ers manufactured by different vendors to 
communicate easily. Software based on 
standard languages, standard interfaces, 
and standard utilities should be able to 
run on equipment from different vendors. 
Users trained on systems supporting 
these standards should be able to readily 


use other systems built on the same con¬ 
ventions. 

The potential benefits from using such- 
standards are enormous. Recognition of 
this fact has stimulated increased user 
demand for software, data interchange, 
and communications standards. How¬ 
ever, these benefits do not come without 
cost. Vendors who have developed and 
are marketing systems built on older, 
nonstandard technology cannot afford to 
abandon those systems before realizing 
some acceptable measure of return on in¬ 
vestment. Similarly, most users cannot 
afford to discard current offerings hoping 
to realize future benefits from standards- 
based systems. 

Fortunately, few systems are totally 
“frozen” for long periods of time. Appli¬ 
cations software requires maintenance. 
Operating systems are updated. Hard¬ 
ware is replaced. When user demand is 
great, the marketplace typically responds 
with tools and translators to ease the tran¬ 
sition to new systems built upon stan¬ 
dards. 

Level of standardization. A standard 
may be adopted for use solely within an 
office or a company. Such standards of¬ 
ten take the form of restricting purchases 
to specific products from particular ven¬ 
dors. Of course, an organization may 
choose to use standards that have wider 
recognition. The standard may have been 
developed and/or granted recognition by 
a trade or technical association, a na¬ 
tional standards body, a national govern¬ 
ment, or an international standards or¬ 
ganization. 

Typically, the higher the level of the 
recognizing entity, the stronger the sup- 
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port for the standard. However, numer¬ 
ous standards have been developed under 
the auspices of national and international 
standards bodies and have still failed to 
achieve a high degree of use. Clearly 
other factors must be involved in deter¬ 
mining the success of the standard. 

Additional factors. While there may 
be general agreement as to the need for a 
particular standard, insurmountable bar¬ 
riers may yet remain to success. For a va¬ 
riety of reasons, it may be simply too late 
for a standard to gain support in the mar¬ 
ketplace. Major users and suppliers may 
have already committed to an alternative 
solution that would be prohibitively ex¬ 
pensive to change. Thus, timeliness is an 
important factor to be considered when 
developing standards. 

Of course, the timing may be right and 
the need great, but a successful standard 
still may not be feasible. This may be due 
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to the existence of a number of different 
implementation approaches that lack a 
“common denominator.” That is, no stan¬ 
dard specification could cleanly replace 
each of these alternative “boxes.” 

Even when the timing seems right and 
agreement has been reached on the type 
of standard to be developed, there are still 
some factors that can impede standards 
development. A couple of major ex¬ 
amples are “Not Invented Here (NIH)” 
and “gold-plating.” Even the most dedi¬ 
cated of committees can succumb to these 
tendencies in their search for a neutral 
specification or an optimal solution. 

The factors presented here are by no 
means a complete set. Nor are they mutu¬ 
ally independent. Hopefully, they serve 
to illustrate some of the “secrets” to suc¬ 
cess for standards developers. 

Recent developments. Today, large 
organizations like General Motors and 
Boeing are faced with problems that will 
benefit from standards-based solutions. 
Similarly, governments around the world 
recognize the usefulness of information 
technology standards. Many have 
mounted successful, national standardi¬ 
zation efforts. There is a growing concern 
that these efforts will produce a variety of 
different national standards, which could 
act as non-tariff trade barriers and con¬ 
strain the worldwide exchange of goods 
and services. 

Because of such concerns, product and 
service providers who seek an interna¬ 
tional marketplace are now motivated to 
support and accelerate the development 
of international standards. In recent 
years, headlines have announced strong 
industry support for standardization. 

This support has led to the formation of 
organizations, coalitions, and consortia 
with missions that address standards. 

Industry support. For example, in the 
Manufacturing Automation Protocol and 
Technical Office Protocol (MAP/TOP) 
Users Group, users have thrown their col¬ 
lective marketplace clout behind se¬ 
lected international standards. The Cor¬ 
poration for Open Systems is developing 
test methods for validating the confor¬ 
mance of computer communications 
products to open systems interconnec¬ 
tion standards. The Software Productiv¬ 
ity Consortium program includes the de¬ 
velopment of reusable software tools, 
which require a standard software inter¬ 
face. 

The Information Technology Require¬ 
ments Council (ITRC) was formed re¬ 
cently to address the development and 
implementation of standards-based in¬ 
formation technology. ITRC is a direct 
outgrowth of the North American MAP/ 
TOP Users Group. It is a not-for-profit, 


user-vendor-govemment coalition that 
will address the development of user re¬ 
quirements and the implementation of 
standards-based information technology 
to meet these requirements within the 
context of economic competitiveness. 
Others formed in recent years include the 
OSI Implementors Workshop, X/Open, 
the Open Software Foundation (OSF), 
the Promoting Conference for Open Sys¬ 
tems Interconnection (POSI), the Stan¬ 
dards Promotion and Applications Group 
(SPAG), and the North American ISDN 
Users Forum. The list is impressive and 
growing. 

Europe 1992. The European Commu¬ 
nity has decided to establish a unified 
market by 1992. Governmental represen¬ 
tatives of the Common Market nations 
are in the process of drafting common 
standards that, for the first time, will per¬ 
mit qualifying products to be sold 
throughout Western Europe. When these 
standards are in place, Europe will sur¬ 
pass the United States as the largest world 
market. 

Recognizing the implications of this 
major European initiative and its rela¬ 
tionship to standards, the Subcommittee 
on Science, Research, and Technology of 
the US House of Representatives Com¬ 
mittee on Science, Space, and Technol¬ 
ogy held hearings this July on “Interna¬ 
tional Standards and US Competitive¬ 
ness” (see Computer, September 1989, 
pp. 74-75). These hearings underscored 
the growing importance of internation¬ 
ally recognized standards to organiza¬ 
tions and countries wishing to participate 
in the global economy. 

The task that remains. Significant 
progress has been made in the develop¬ 
ment of information processing stan¬ 
dards. Standards exist or are under devel¬ 
opment for many aspects of computer and 
communications systems, including 
software and data. However, the job is far 
from finished. 

As technology advances, new stan¬ 
dards and revisions to existing standards 
will be required to accommodate these 
advances. Further, as users from differ¬ 
ent communities and disciplines become 
more dependent on information technol¬ 
ogy, they will discover the need for appli¬ 
cation-specific standards. These com¬ 
munities would be well advised to first 
consider the applicability of existing 
standards before embarking on new de¬ 
velopments. 

Adopting existing standards, even 
with some tailoring or customizing, will 
save considerable time and resources, 
which can instead be turned into ad¬ 
vances in their principal field of en¬ 
deavor. 
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Transistor coinventor Shockley dead at 79 


William Shockley, who invented the 
transistor in late 1947 in collaboration 
with John Bardeen and Walter H. Brattain 
» at Bell Laboratories, died August 12 at his 
’ home on the campus of Stanford Univer- 
| sity at the age of 79. 

The three men teamed to develop their 
first semiconductor device during what 
Shockley later called the “magic month.” 
Their development of this seminal inno¬ 
vation of the electronic age won them the 
Nobel Prize for physics in 1956. 

The semiconductor company Shock- 
ley founded in 1955 after he left Bell Labs 
led to the birth of Silicon Valley. Later, a 


rebellion by eight employees of Shockley 
Semiconductor set the stage for other key 
inventions. Two of those who split with 
him were Robert Noyce and Gordon 
Moore. Noyce went on to coinvent the in¬ 
tegrated circuit, and Moore later invented 
the microprocessor. 

For nearly two generations, practically 
every Silicon Valley start-up company 
could trace its lineage back to Shockley 
Semiconductor. 

Shockley was embroiled in contro¬ 
versy during the latter years of his life. He 
became involved in a dispute over “retro¬ 
gressive evolution,” his belief that intel¬ 


ligence was genetic and that some races 
were genetically inferior. 

Shockley, in fact, considered his work 
in the genetic field more important than 
his discovery of the transistor. According 
to his wife, Emmy, Shockley continued 
analyzing data and drafting papers on ge¬ 
netics until a few weeks before his death. 

Shockley received his BS degree from 
Caltech in 1932 and his doctorate in phys¬ 
ics from MIT in 1936, the same year he 
joined Bell Labs, AT&T’s research arm. 
He began lecturing at Stanford in 1956 
and was professor emeritus of electrical 
engineering there at the time of his death. 


December 31 set as entry deadline for 1989 Gordon Bell Prize 


December 31 has been established as 
the deadline for entries for the 1989 Gor¬ 
don Bell Prize, which for three years has 
recognized outstanding achievements in 
the application of parallel processing to 
scientific and engineering problems. 

The prize winners will be announced in 
the spring of 1990, according to IEEE 
j Software, which administers the judging. 

The prize is sponsored by Gordon Bell, 
a former National Science Foundation 
division director and now vice president 
of engineering at Ardent Computer Sys¬ 
tems. Bell offered to sponsor the prize’s 
two $1,000 annual awards for 10 years 
during a May 1986 interview in IEEE 
Software. 

Bell Prize entries are invited in three 
categories — performance, price/perfor¬ 
mance, and compiler parallelization. 
Awards of $1,000 each will be made in the 
two categories the judges rule showed the 
best results. 

Entrants in the performance category 
must show that the submitted program 
runs faster than any other comparable en¬ 
gineering or scientific application. In the 
price/performance category, entrants 
must show that the performance of the 
application divided by the cost of the sys¬ 
tem is higher than any other entry. In the 
compiler parallelization category, 
judges will look for the compiler/applica¬ 
tion that generates the most speedup. 


All submitted programs must solve a 
problem that is considered a routine pro¬ 
duction run, for instance, making daily 
weather predictions or solving an impor¬ 
tant engineering or scientific problem. 

Each entry should be described in a 
three- to four-page summary and should 
be submitted to: 1989 Gordon Bell Prize, 
c/o IEEE Software, 10662 Los Vaqueros 


Circle, PO Box 3014, Los Alamitos, CA 
90720-1264. 

Gordon Bell also sponsors a separate 
set of awards independent of the Bell 
Prize called the Gordon Bell Awards for 
Perfect Benchmark. They are admini¬ 
stered by the Center for Supercomputing 
Research and Development at the Uni¬ 
versity of Illinois. 


IEEE applicants sought for congressional 
fellowships 


The IEEE United States Activities 
Board is inviting IEEE members to 
apply for 1990-91 IEEE-USA Con¬ 
gressional Fellowships. Through this 
program, electrical and electronics 
engineers and applied scientists are 
competitively selected to serve a year 
on the staff of a senator, congressman, 
or congressional committee. 

Fellows are selected on technical 
competence, ability to serve in a pub¬ 
lic environment, and on evidence of 
service to the IEEE and the profession. 
Fellows must be US citizens and must 
have been in the IEEE for at least four 


years. Age, sex, creed, race, ethnic 
background, and partisan political af¬ 
filiations are excluded as criteria. 

At least two awards will be made; 
more may be added if additional fund¬ 
ing sources are found. 

Further information and applica¬ 
tion forms can be obtained by calling 
W. Thomas Suttle at (202) 785-0017 
or by writing to: Secretary, Congres¬ 
sional Fellows Program, IEEE-US 
Activities, 1828 L St. NW, Suite 1202, 
Washington, DC 20036. 

Applications must be postmarked 
by March 30, 1990. 
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Second Annual Conference on Innovative 
Applications of Artificial Intelligence - IAAI90 

May 1-3,1990 Georgetown University, Washington, DC 


► Call For Papers 


The Second Annual Conference on Innovative 
Applications of Artificial Intelligence will high¬ 
light twenty-five (25) of the most innovative AI 
applications which actually have been deployed. 
The conference is complementary to the National 
Conference on Artificial Intelligence, which 
emphasizes scientific and engineering research 
results in the field. The conference format will he 
a series of plenary and panel discussions. We 
encourage authors to submit papers describing 
the innovative applications of expert systems as 
well as systems employing natural language, 
knowledge acquisition, machine learning, compu¬ 
tational vision, speech, robotics and other AI 
technologies. 

► Program Co-Chairs 

Alain Rappaport 
Neuron Data 

Reid Smith 

Schlumberger Laboratory for Computer Science 

If you would like to submit a paper, please send 
five copies. Papers should be no longer that five 
to eight, 8 1/2" by 11", single-spaced pages. Sub¬ 
missions will be reviewed along the following 
dimensions: 

► Definition of the problem; 

► Description of the use of AI technology 
in the application (please note if it is an 
embedded or a stand alone system); 

► Innovations or technological break 
through brought by the application; 

► Your criteria for a successfully deployed 
application (please note that these criteria 
should be specific to your actual experience); 


► The nature and estimate of the payoff to 
your organization; and 

► Outline of how long your system has 
been deployed, development costs 
including labor, and the length of time 
to transfer the system successfully into 
the field. 

Please indicate two keywords describing the 
domain of application and the innovative AI tech¬ 
nology. We encourage successful authors to pre¬ 
sent their results using some audio-visual medium 
such as videotape or live computer projection. 
Selected applicants will receive the Annual 
Innovative Application Award and will he high¬ 
lighted in the AI Magazine. AAAI Press also pub¬ 
lished the results of the conference into a book, 
Innovative Applications of Artificial Intelligence. 

► Deadline Dates 

Submission of paper to AAAI office: 

December 12,1989 
Program Committee Meeting 
January 13,1990 
Notification to authors: 

January 19 1990 

Return of Revised, Final Paper to AAAI office: 
March 2,1990 

Send 5 copies of your paper to: 

IAAI-90 • AAAI • 445 Burgess Drive 
Menlo Park, CA 94025 • (415)-328-3123 

For Registration information, contact the 
AAAI office 

AAAI • 445 Burgess Drive • Menlo Park, CA 
94025 (415-328-3123 • FAX (415)321-4457) 
CSNET: IAAI@aaai.org 










PRODUCT REVIEWS 


Editor: Richard Eckhouse, UMASS-Boston, Harbor Campus, Boston, MA 02125, phone (617) 929-7963; Compmail+, r.eckhouse 


Generating applications programs 


Matrix Layout by Matrix Software is a 
set of programs designed in part to pro¬ 
vide a Macintosh-like interface, along 
with some of the features of programs 
such as Sidekick. It includes the pro¬ 
grams Layout, Paint, HelpMaker, Tutor, 
and Desktop. Some of its features suc¬ 
ceed better than others. 

The designers of Matrix Layout seem 
to have targeted the inexperienced com¬ 
puter user, but it’s not clear that that 
group would be completely successful in 
using the package. 

Layout 

The company clearly considers the 
Layout portion of the package to be the 
centerpiece. It promotes Layout as the 
nonprogrammer’s way to create pro¬ 
grams, as well as the programmer’s way 
to simplify generation of usable source 
code. 

Layout is based on the concept of 
flowcharts. You can create a flowchart in 
Layout by specifying the contents of 
each block. You can turn the flowchart 
into an executable program in a number 
of ways. Layout can create an executable 
(exe) file, or it can generate source code 
for Microsoft QuickBasic, Turbo Pascal, 
Microsoft C, Lattice C, or Turbo C. You 
can then compile the code or make addi¬ 
tional modifications to it before compila¬ 
tion. The documentation recommends 
that, if you know one of the high-level 
languages, you use Matrix Layout to cre¬ 
ate an exe file and create another with 
your compiler. Then use whichever ex¬ 
ecutable module is smaller. 

A weak part of the package is the lack 
of documentation about the compilation 
process. Nowhere in the extensive Help 
pages or in the Tutor does it explain 
which files must be accessible to your 
compiler. The documentation also d<?es 
not tell you that batch files provided as 
part of the Layout package can be used 
from the DOS prompt to carry out com¬ 
pilation, referencing the appropriate files 
in the Layout subdirectories. 

It takes a bit of unsuccessful compila¬ 


tion and hacking around in directories to 
figure it all out. The documentation also 
fails to tell you with which version of 
each compiler the generated source code 
will be compatible. Pascal code gener¬ 
ated by the reviewed version could be 
compiled by Turbo Pascal 4.0. The Basic 
code could be compiled with QuickBasic 
4.0, but the resulting exe file (based on 
the sample flowchart provided with the 
package) did not run, hanging the ma¬ 
chine instead. When asked about this, 
technical support at the company said 
that they did not know of any specific 
problems with QuickBasic 4.0, but stated 
that all prior known problems had been 
corrected when they upgraded for Quick- 
Basic 4.5, Turbo Pascal 5.0, and Turbo C 
2.0. However, if you buy the package 
from a dealer instead of directly from the 
company, you may still get the old ver¬ 
sion, which you can then upgrade for 
free by calling the company. 

The lack of examples and of a printed 
manual may limit the ability of nonpro¬ 
grammers to use Layout to create pro¬ 
grams. The explanations given in the 
Help pages (which are part of the system, 
not printed) for If-Then-Else construc¬ 
tions and While loops may not be ade¬ 
quate to teach people who have never 
programmed and are trying to build their 
first flowchart. Also, the developers as¬ 
sume some understanding in the market 
population of the linear logical thought 
that must go into the development of a 
flowchart. However, this is the hardest 
thing for new programmers to grasp. 
Without more examples, most new pro¬ 
grammers will have a very difficult time 
creating working programs. 

Paint 

The Paint program lets you create pic¬ 
tures, either by drawing them or using 
clip art. You can also specify colors and 
fill patterns and include text in the graph¬ 
ics. The Paint program is probably the 
most fun part of the package. The intent 
is to develop pictures in Paint for use by 
the programs developed in Layout. 


Tutor 

Matrix Layout does not include an ex¬ 
tensive manual. Instead you get several 
resources, including a 10-minute video, a 
tutor, and system help. The video shows 
you some of the things you can do with 
the package. The Tutor supposedly 
teaches you how to use it. 

The Tutor is of limited use. It is essen¬ 
tially an on-screen manual, but it does 
not reinforce the information by taking 
you through an actual session (prompting 
for specific keystrokes, etc.). This leaves 
you trying hard to remember lots of steps 
or, worse yet, taking written notes. 

(While using the Tutor, you cannot ac¬ 
cess the Notepad feature of the Desktop, 
so it’s not possible to type a few notes 
and then return to the Tutor. This would 
be a nice feature to add.) 

The other difficulty with the Tutor is 
that, at least on a VGA monitor, Desktop 
defaults to small type, which makes it 
very difficult to read for any length of 
time. Furthermore, while you can modify 
the color of the screens, it does not seem 
possible to control the type style used by 
Desktop on its own screens. 

Lastly, the Tutor has a number of er¬ 
rors that could have been fixed using a 
spell checker or caught through careful 
proofreading. 

HelpMaker 

HelpMaker lets the program designer 
create help screens that will correspond 
to specific portions of a finished pro¬ 
gram. In this instance the package, pro¬ 
vides quite adequate examples, since the 
help pages referenced from within the 
Matrix Layout programs were built using 
HelpMaker. 

Desktop 

The gateway to all the programs in 
Matrix Layout is the Desktop program, 
which sits on top of DOS and insulates 
you from it. The manufacturer claims — 
and it seems to be true — that in some 
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cases a command to Desktop will exe¬ 
cute more quickly than an analogous 
DOS command line entry. For example, 
checking disk capacity is very fast from 
Desktop. 

From Desktop you can do a variety of 
things, including executing those pro¬ 
grams that are part of the Matrix Layout 
package or any other program small 
enough to fit into the available memory. 
There may not be enough memory left 
over to load some application programs, 
because the Desktop program takes 
around 117 Kbytes when loaded. When 
you exit Desktop, only 59 Kbytes are 
freed. Nonetheless, Desktop may be the 
most useful of the programs included in 
the package. 

Desktop has a number of features: 

• Clipboard lets you copy parts of pic¬ 
tures from Paint for use in Layout or 
copy pictures from one Paint file to an¬ 
other. 

• Notepad provides a box for typing 
notes, which you can then save to an 
ASCII file. You can also call up an exist¬ 
ing file and add to it. However, you can¬ 
not print from within Notepad, although 
you can print from the files when run¬ 
ning Desktop. Notepad has wordwrap, 
but only after you enter 77 characters. A 
shorter line would make it easier to go 
back and forth between Notepad and the 
ASCII mode of word processing pro¬ 
grams. Notepad defaults to overtype 
mode, which also differs from a lot of 
word processors. You can toggle be¬ 
tween overtype and insert mode using 


the insert key, but the screen doesn’t tell 
you which mode you are in. 

• Install lets you set the default drive 
and change screen and window colors. 

• Calculator provides a four-function 
calculator with memory. To enter data 
you can use either the numeric keypad or 
the number keys above the letters. You 
do not have to use Numlock if you plan 
to use the numeric keypad. Since Calcu¬ 
lator does not use a menu bar, the menu 
bar stays blank when you return to Desk¬ 
top. Pressing F10 to get the menu will 
cause a display of the pull-down sub¬ 
menus. 

• Calendar displays the current month, 
with the current date indicated. Page up 
and page down will display prior and fu¬ 
ture months. Whereas most other aspects 
of Matrix Layout use the Esc key to re¬ 
turn to the main menu, Calendar uses F2. 

• Clock shows an analog clock on the 
screen with a moving second hand. 

• Convert lets you switch between for¬ 
mats, such as converting a dBase III file 
to the format used for Matrix Layout 
card files or converting a Dr. Halo graph¬ 
ics file to a Matrix Paint file. 

• Font Manager lets you add to or de¬ 
lete from a font file. 

• Options lets you specify which sort 
method to use for the desktop’s display 
of current directory entries. You can 
choose to sort by name (numeric file 
name first, followed by alphabetic order¬ 
ing), by file type (in alphabetic order of 
the name suffix), by date and time (most 
recent file first), or by file size (smallest 
first). 


Programmers wanting to use Matrix 
Layout to write a program in a com¬ 
puter language follow the same steps 
as in creating a ready-to-run program. 
Layout will assign an extension for the 
main file name based on the language 
chosen. 


Summing up 

Desktop has some nice, useful fea¬ 
tures, although if you have used DOS for 
a long time it may seem more cumber¬ 
some to use than just setting up a few 
batch files and having a memory-resident 
program such as Sidekick. The Layout 
portion of the package does not seem 
particularly useful for a nonprogrammer 
or a new user. However, there are two 
situations in which a seasoned program¬ 
mer might want to consider it. First, if 
you want to use various graphics in a 
program, you can use Layout to generate 
those portions of a program, then fill out 
the generated source with the rest of the 
code. Secondly, you can use Matrix Lay¬ 
out to generate friendly programs for 
new users, with lots of easily accessible 
built-in help screens, pull-down menus, 
and light bars. 

System requirements 

Matrix Layout can run on systems 
with a hard drive or on single or dual 
floppy systems. It can run with or with¬ 
out a mouse. It requires 256 Kbytes of 
memory and a graphics adapter. The re¬ 
tail price is $149.95. 

Matrix Software Technology is located 
at One Massachusetts Technology Cen¬ 
ter, Harborside Dr., Boston, MA 02128, 
phone (617) 567-0037. — V. Barr 
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An implementation of the 
schematic pseudocode approach 


Schemacode, version 1.5.2, imple¬ 
ments the schematic pseudocode, or 
SPC, model for the software develop¬ 
ment process. SPC is based on a 
top-down structured approach using 
diagrams, or schemas, to represent the 
program control structures. The use of 
schemas is intended to make the repre¬ 
sentation of the program logic independ¬ 
ent of the target programming language. 

It also acts as a form of automated 
documentation that can be interpreted 
without knowledge of the underlying 
language. This review concentrates on 
the Schemacode product — the implem¬ 
entation of the SPC paradigm. (For a de¬ 
tailed exposition of schematic pseudo¬ 
code, refer to the “Computing Practices” 
column of the November 1986 issue of 
Communications of the ACM.) 

Schemacode consists of a full-screen 
editor and a code generator for producing 
source files in the target programming 
language. For this review I used the C 
language implementation of Schemacode 
and the Microsoft C, Version 5.1, com¬ 
piler. Separate versions for Fortran, 
dBase III, Pascal, Basic, and Cobol are 
also included on the installation disks. 

The editor is used to build the program 
much like you would construct an outline 
using a top-down approach. After you 
define the set of top-level tasks, you 
break each task down into less detailed 
units until the problem is represented as 
a manageable set of tasks. Schemacode 
refers to the specification of a task as a 
refinement. Language-specific details of 
the program are added as you define the 
program structure in more detail. 

The editor uses pull-down menus to 
access many of its features, such as list¬ 
ing the set of all refinements, printing the 
refinements, inserting schematic control 
structure representations into the pro¬ 
gram, zooming in and out of refinements, 
and moving groups of refinements within 
the program. Hot keys are available for 
many of the menu functions. 

The editor functions much like a com¬ 
mercial programmer’s editor, except that 
it includes facilities for dealing with the 
schematic representation of the program 
control structures and for manipulating 
refinements at any level of abstraction. 
This makes it particularly useful at the 
progrant design stage of software devel¬ 
opment. 

Schemacode lacks many of the more 
sophisticated features of a mature 
programmer’s editor, such as multilevel 
undo, building of complex macros, 
movement of text within and between 


files, and manipulation of files within the 
DOS directory structure. I expect this 
would prove a major stumbling block to 
Schemacode’s gaining acceptance from 
professional programmers. 

Once you have fully defined the prob¬ 
lem and coded the set of refinements into 
the target language, Schemacode will 
generate a file of source code in the pro¬ 
gramming language. The narrative and 
operational comments built up during the 
development process become part of the 
documentation when the final source 
code is generated. In a sense. Schema- 
code also acts as an automated documen¬ 
tation tool. 

After you are satisfied with the source 
code, you can compile it from within 
Schemacode using the compiler of your 
choice. If any errors are encountered dur¬ 
ing this phase, you remain within Sche¬ 
macode with the cursor positioned near 
the offending statement, and the com¬ 
piler error message displays in a message 
window. If no errors occur, you can exit 
the environment and link the generated 
object modules with your standard 
linker. The system worked well with all 
of the test cases that I used and generated 
very good source code. 


One especially nice point about Sche¬ 
macode was the listings of the pseudo¬ 
code generated from within the environ¬ 
ment. I used both a dot matrix printer 
and a laser printer for the output. With 
the laser printer, the format of the list¬ 
ings was presented so well that it could 
easily act as the sole documentation. 

It is difficult to say how well the sche¬ 
matic pseudocode approach and Schema- 
code would work in a production envi¬ 
ronment with large-scale projects over an 
extended period of time. Schemacode In¬ 
ternational has reported some very im¬ 
pressive results in studies they con¬ 
ducted, especially in the area of program 
documentation. I plan to experiment fur¬ 
ther with this $250 product in future soft¬ 
ware projects. If you are engaged in 
teaching the basics of program structure, 
design, and documentation, I think Sche¬ 
macode would prove to be a valuable 
tool — certainly one worth your time to 
investigate. 

Contact Schemacode International 
through PO Box 6079, St. “A,” Mon¬ 
treal, Canada, H3C 3A7, phone (514) 
683-8693. —D. McAuliffe 
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E 1.5.2 - Schemacode Internati 
-Author : John Doe 
-Description: Finds the roots of a 
quadratic polynomial 
2! Declare variables 
mainO 
I 

Display introductory message 
-Compute roots for each a,b,c entered 


| Ask for a, b and c coefficients 
2 Compute the discriminant 
Q Display results according to solutii 

-Ask for another polynomial 

printf("SnAnother one ? (y/n) : 
answer=toupper(getch()); 


Press E 


! to CANCEL Press FI for HELP 


This Schemacode screen shows an editing step. The schematic loop construct 
contains three operation comments, labeled 05, 06, and 07; one narrative com¬ 
ment (preceded by a dash); two C programming statements; and one exit condi¬ 
tion (also in C). The programmer has pulled down the Move menu and high¬ 
lighted the command to Zoom In a refinement. 
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The Voice Master PC Digitizer from Covox consists of a half-size board and a 
microphone, shown here, and two software packages (not shown). 


Talking computers 


Just about everyone talks to their com¬ 
puter. I’ve been muttering to computers 
since the first time I sat down in front of 
a TTY. Before that, I muttered to card 
punches. Lately, however, it seems my 
PC is beginning to understand me. 

The ability to enter commands by 
voice has tremendous possibilities for 
people with restricted hand or finger 
movement. It also allows use of the PC 
in applications where the user’s hands 
are busy doing other things or in envi¬ 
ronments that could damage the key¬ 
board. Even in the typical workplace 
voice input has the potential for increas¬ 
ing productivity. Touch typists can keep 
their hands over the standard portion of 
their keyboards and enter commands re¬ 
quiring any of the special keys by voice. 
They also will not have to remember the 
arbitrary keystrokes that make up most 
of those commands. People using graphi¬ 
cal interfaces with a mouse will not have 
to let go of the mouse to use the key¬ 
board or move the mouse from a work 
area to a command menu area. 

This review will cover two voice rec¬ 
ognition systems, the Voice Master from 
Covox and the Bug Voice Command 
System from Command Corp. My pri¬ 
mary concern was to determine how well 
they recognized speech. My secondary 
concern was to determine how easy they 


Voice Master 

The Voice Master PC Digitizer from 
Covox is a low-cost ($149.95) sound dig¬ 
itizer and speech recognition system. It 
consists of a half-size 8-bit card for the 
PC-AT bus, a microphone, and two soft¬ 
ware packages. The Voice Master pack¬ 
age (version 2.52) provides a sound/ 
voice editor and a program interface for 
integrating voice recognition directly 
into any program. The Voice Master Key 
package (version 1.01) provides a termi¬ 
nate and stay resident tool that simulates 
user keyboard input in response to spo¬ 
ken commands. Each software package 
comes on its own disk and has its own 
manual. Both require DOS 2.0 or higher 
and 256 Kbytes of memory. 

Installing the board was a snap. A set 
of four jumpers changes the board’s port 
address. This makes it possible to resolve 
conflicts with other boards. A potenti¬ 
ometer can be adjusted with a small 
screwdriver to calibrate the board. I had 
no problems using the default port set¬ 
tings, and the board came calibrated cor¬ 
rectly from the factory. 

For word recognition, the program 


takes 400 samples a second for the 
length of the word. Each sample is as¬ 
signed one of 256 uniformly spaced am¬ 
plitude levels. The samples are then nor¬ 
malized into 100 bytes and stored as a 
word template. You can store 64 word 
templates in memory. Each word can be 
trained multiple times, with a recom¬ 
mended minimum of two. Training a 
word more than twice does not add a 
third template; instead, it causes one or 
both of the word templates to be aver¬ 
aged with the new training data. 

A word to be recognized is compared 
against the stored templates. The pro¬ 
gram generates a score for each compari¬ 
son. If no score is acceptable, no word is 
recognized. If two scores fall within the 
acceptable range, they are compared to 
each other; if they are too similar, an er¬ 
ror is generated. It’s possible to get from 
the system the two most acceptable 
words as best and second-best guesses. 
Of course, if only one score falls within 
the acceptable range, the word is recog¬ 
nized. A sensitivity value adjusts how 
close the match must be to the template 
and also how different it must be from 
all other templates for the system to rec¬ 
ognize a word. Sensitivity ranges from 1 
to 4, with 4 the least sensitive and a de¬ 
fault of 2. 

The Voice Master package consists of 
the manual and distribution disk. The 39- 
page manual does a good job of explain¬ 
ing how to install the hardware and how 
to use the software. The vmedit program 


(version 2.51) is a sound editor used for 
recording, playback, and editing (includ¬ 
ing dubbing) sounds. The program also 
includes a real-time oscilloscope display 
of input sounds. This lets you check the 
hardware calibration and practice talking 
into the system to maintain a consistent 
volume (called in the manual “correct 
microphone procedure”). 

The playback features are available 
only if you also have the Speech Thing. 
The Speech Thing is a sound/voice out¬ 
put device sold by Covox as a separate 
package for $69.95. 

I found it interesting to experiment 
with the editor, but I used the oscillo¬ 
scope only to test the system calibration 
and practice my microphone procedure. 

It has no speech recognition functions. 

The program recog.exe (version 2.52) 
is a terminate and stay resident program 
(about 28 Kbytes) that allows a program 
to create word templates and perform 
voice recognition via software interrupt 
(using any interrupt between 64 and 126) 
and by directly addressing recog’s data 
segment. Some functions, like training a 
word template and performing voice rec¬ 
ognition, are done via the interrupt, 
while others, like loading and saving the 
word template files or changing the sen¬ 
sitivity, are done by accessing recog’s 
data segment directly. Between the as¬ 
sembly language and Quick Basic ex¬ 
amples and Covox’s technical support 
people, I had no problems writing a C 
program that interfaced with recog. 
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The distribution disk also contained a 
GW-Basic program fragment called 
finder.bas. Including this fragment in a 
GW-Basic program gives GW-Basic pro¬ 
grammers the ability to interface with re¬ 
cog via named routines. Several ex¬ 
amples also use GW-Basic. 

The Quick Basic example is a simple 
demo that has you train the system to 
recognize the numbers 1 through 5. An 
exe file was provided, so I tried it. The 
results did not bode well. In my first try, 
out of 15 samples it only got five correct, 
recognized six incorrectly, got an error 
indicating no match for two, and 
matched two to two templates. I saw no 
pattern. About two weeks after my first 
two tries, I retrained the numbers for a 
third time. This time all 15 samples were 
recognized correctly! 

The program I wrote did much the 
same except with a larger vocabulary. I 
tried random word lists, names, the sym¬ 
bols on a calculator, and all 10 digits. 

The results were very disappointing. I 
had 97 words overall and racked up 880 
trials. Only 62.5 percent of the trials re¬ 
sulted in the correct word being recog¬ 
nized, while 24.4 percent resulted in two 
words being matched (but the “best 
guess” was correct). In 3.8 percent of the 
trials the second guess was correct. In 
9.3 percent of the trials either no word 
was matched or both guesses were 
wrong. 

About halfway through the trials I 
called technical support. I was told to 
experiment with the microphone posi¬ 
tion, sensitivity value, and my speaking. 

I had to be sure to use the same expres¬ 
sion and volume. I tried, but it didn’t 
seem to help the recognition statistics. I 
did notice that multisyllable words had a 
better track record. However, the system 
frequently confused words that appeared 
to have nothing in common. 

The Voice Master Key package also 
consists of a manual and distribution 
disk. The 78-page manual does a good 
job of explaining the Voice Master Key 
system. I noticed some duplication of in¬ 
formation, such as installation instruc¬ 
tions for the board and correct micro¬ 
phone procedure. However, since most 
people tend to skim manuals, this is 
probably a good thing. 

You can store up to 64 words in a tem¬ 
plate file, with up to 16 active at any one 
time. You can also have 128 keyboard 
macros, grouped into menus of 16. These 
16 control which word templates will be 
scanned for recognition. The same word 
template keyboard macro can be in more 
than one macro menu, or the same word 
template can trigger two different key¬ 
board macros in two different macro 
menus. 

Each keyboard macro in a menu can 


have 20 keystrokes, including all the 
control, alternate, and special keys. You 
also get three special macro commands, 
DoX, GoX, and Ret. A DoX links two 
macros from the same menu together. 
This allows all 16 macro items in a menu 
to be activated with one voice command, 
allowing the entry of 303 keystrokes. A 
GoX changes the macro menu. This lets 
a voice command be used to switch 
macro menus, which can activate another 
set of 16 word templates. By combining 
GoX and DoX commands, you can link 
all the keyboard macros together, allow¬ 
ing one voice command to trigger 4,849 
keystrokes. The Ret command returns 
control to the previous macro menu. 

The two modes of voice recognition 
consist of continuous mode and manual 
mode. In continuous mode the micro¬ 
phone is always active, and any sound 
over the specified amplitude will trigger 
an attempt at recognition. In manual 
mode you must press a special hot key 
before recognition will be attempted. 
Whenever voice recognition is in prog¬ 
ress, the happy face character appears in 
the upper right corner. 

The default configuration uses only 
black and white. However, you can 
change the colors using vmconfig.exe. 
The vmconfig.exe programs works by 
actually changing the vmkey.com file. 
Not only can you change the colors, but 
you can also change names and exten¬ 
sions of the default template and macro 
files, the port address (to correspond 
with changes made when the board was 
installed), and the hot keys. 

There are two sets of hot keys, one to 
bring up the vmkey display and the other 
to activate voice recognition in manual 
mode. It’s also possible to use the left, 
middle, or right button on your mouse as 
the hot key for manual mode. 

The configuration procedure was easy 
and provides a lot of flexibility for 
smoothly integrating vmkey into many 
different environments. However, when I 
used a mouse button as the vmkey hot 
key, I observed some strange behavior in 
other programs that use a mouse. 

As shipped, vmkey will work on EGA, 
CGA, monochrome, and LCD monitors. 
It’s a simple program to load, having 
only four arguments. You can specify the 
default word template file and keyboard 
macro files to load. You can also specify 
the interrupt vector that vmkey will use. 
An argument tells vmkey to remove it¬ 
self from memory, but to do this, nothing 
can occupy memory “above” vmkey. 

The vmkey display takes up most of 
the screen, but portions of the foreground 
program’s screen are visible. All func¬ 
tions are selected from menus. After 
reading the manual, I had no problem us¬ 
ing the system. The on-line help facility 


displays a screenful of information about 
the current selection. This was moder¬ 
ately useful and eliminated the need to 
refer to the manual for purely syntactic 
questions, such as “Is a sensitivity of 4 
the most or least sensitive setting?” 
However, the on-line help is not enough 
to understand the system — you need to 
read the manual. 

Besides creating word templates and 
keyboard macros, you can 

• test macros by executing them as if 
their voice command were recog¬ 
nized, 

• test the recognition of the word tem¬ 
plates, 

• load and save voice templates and 
macro files, 

• set the sensitivity level, and 

• set the minimum volume to start re¬ 
cording a word template or to start 
word recognition. 

I built a set of 16 word templates and 
macros in one menu for common word 
processing functions. Most of the com¬ 
mands had multiple syllables; some were 
multiple words. The results were disap¬ 
pointing. Of 204 trials, 109 (53 percent) 
resulted in no-recognition errors. An¬ 
other 42 (20.5 percent) resulted in incor¬ 
rect recognitions, meaning the wrong 
command was executed. Halfway 
through I tried retraining the commands 
not being recognized correctly, but it 
didn’t seem to help. Twice when I 
sneezed, the command “backward 
search” was recognized. 

I also tested vmkey with three graph¬ 
ics packages to see how it worked in 
graphics mode. One package used CGA 
graphics mode and the other two EGA 
mode. I experienced several problems in 
graphics mode. First, the happy face in 
the upper right-hand corner turns into a 
dot. Depending on the background, it 
might be visible or invisible. Second, 
when switching to the vmkey display, the 
screen went back to text mode. The 
graphics data was treated as character 
data, which made for some pretty dis¬ 
tracting background behind the vmkey 
display. 

It also appeared that the EGA part of 
my graphics memory was altered by the 
vmkey. When I exited vmkey, my screen 
returned to graphics mode but the graph¬ 
ics data had been altered. When I did the 
same thing from an application that used 
only CGA graphics, the screen image 
was unaltered. Also, my EGA package 
lost mouse cursor tracking after returning 
from the vmkey display, while my CGA 
package did not. In continuous mode 
there was a noticeable performance pen¬ 
alty. My more CPU-intensive package 
was unusable. 

You can also use vmkey through other 
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are enabled and disabled by a command. 
Tpl files hold the voice templates for the 
commands, and vcb files hold the key¬ 
strokes. These files will vary in size. Ex¬ 
cept for the tpl files, the manual explains 
none of this. I had to ask Command 
Corp.’s technical support about it. 

When loaded, the device driver uses 
16,384 bytes of memory. It automatically 
analyzes which interrupts and ports are 
in use and sets itself up so it won’t con¬ 
flict with anything. This requires that the 
device driver be the last thing in your 
config.sys so everything else is already 
set up. While I did not have any prob¬ 
lems, conflicts with software not loaded 
through a device driver can occur. 

The utility programs bug.exe and 
bugu.exe form the user interface to 
the Bug system. The bug.exe program 
helps you create and manipulate the lexi¬ 
con. The bugu.exe program loads the 
lexicon and sets the system up for voice 
recognition. 

Bug.exe automatically senses the type 
of video board installed and comes up in 
color if the board will support it. You 
cannot change the colors or use just 
black and white. 

The manual devotes only 10 pages to 
designing, creating, and training a lexi¬ 
con. It explains all the major steps, but 
almost none of the minor ones. The pro¬ 
gram is menu driven, and once I started 
building my own lexicon, I had very 
little trouble. Still, it would have been 
nice to read more about it first. Pressing 
FI gives you context-sensitive help 
(definitely helpful). 

With the standard memory a lexicon 
can have 100 commands, 54 of which 
can be active at any time. You can pur¬ 
chase more memory from Command 
Corp. to double the total number of com¬ 
mands, but the limit of 54 active com¬ 
mands will remain. 

Commands are grouped into command 
sets. A single command may belong to 
multiple command sets. The number of 
command sets you can have is quite 
large. I created 50 before getting tired. 
When a command is activated, three 
things can happen: it can enable a group 
of command sets, disable a group of 
command sets (including the ones to 
which it belongs), and enter up to 30 
keys into the keyboard buffer. 

Three special “command set names” 
let you map any words you want to them 
to turn the microphone off, turn it back 
on, or toggle its current state. The man¬ 
ual mentioned but did not explain how to 
actually use this feature. The readme file 
gave more details, but I figured out the 
process by looking at the demo lexicon. 

One of the demos is a set of 10 words 
corresponding to CAD commands. Train¬ 
ing was no problem, and in my first test 


The Bug Voice Command System from Command Corp. includes the Bug Com¬ 
puter, documentation, Dynamic Lexicon software, and a microphone. 


bus. The system requires DOS 3.x or 4.x 
and 512 Kbytes of memory. 

I installed the Bug Computer without 
problems. It has no jumpers or switches 
to set. It contains a 25 MHz speech rec¬ 
ognition computer and enough memory 
for 100 commands. The manual contains 
straightforward installation instructions, 
but doesn’t explain anything about the 
hardware. For instance, it doesn’t tell 
you what the bottom jack is for or how 
the hardware analyzes your voice input. 

The software, which is not copy pro¬ 
tected, comes on one 5.25-inch diskette. 

It is installed via a batch file contained 
on the distribution disk. This batch file 
will install the software into the Bug sub¬ 
directory (which it creates) off of the 
root directory on drive C. The manual 
also explains that you can install the soft¬ 
ware manually into any directory that 
you want by copying the files into that 
directory and adding the device driver to 
your config.sys file. 

The disk space required for a lexicon 
will vary depending on the number of 
words in the lexicon. Each lexicon con¬ 
sists of three files with suffixes of sub, 
tpl, and vcb. Sub files are always 1,094 
bytes long and hold the information 
about which command belongs to each 
command set and which command sets 


programs using software interrupts. The 
default interrupt is 78H, but you can set 
the interrupt to use with a switch on the 
command line when vmkey is loaded. 

All the vmkey functions available from 
the vmkey display are available through 
interrupt. 

It’s possible that with repeated prac¬ 
tice and tuning of the command set, I 
could have achieved acceptable recogni¬ 
tion levels. However, that limits the use¬ 
ful environment of this board to one 
where the users are willing to invest an 
appreciable amount of time and effort in 
learning how to use it. Given those cir¬ 
cumstances, the installation flexibility, 
programming interface, and power of the 
keyboard macros make this a good 
choice. 


Bug Voice Command 
System 


The Bug Voice Command System 
from Command Corp. ($913) simulates 
user keyboard input in response to spo¬ 
ken commands. It consists of the Bug 
Computer, a microphone, the Bug soft¬ 
ware package (version 1.30), and a 60- 
page manual. The Bug Computer comes 
on a full-size 8-bit card for the PC/AT 
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pass all 10 words were recognized. How¬ 
ever, in my second and third test passes 
none of the words were recognized. I ad¬ 
justed the microphone, and in my fourth 
pass eight words were recognized with¬ 
out error. I had to repeat two words once. 
The microphone is very sensitive to posi¬ 
tion. You should hold it a finger’s width 
from the comer of your mouth. During 
passes two and three, I had pushed it fur¬ 
ther away. 

I had a few problems building my lexi¬ 
con. You cannot correct a keystroke after 
typing it. The only thing you can do is 
delete the command and start over. You 
cannot enter FI 1 or F12 as part of a key¬ 
board macro. You also cannot distin¬ 
guish between keys on the numeric pad 
and keys on the standard part of the key¬ 
board. The technical support person I 
spoke to said that the function key and 
numeric pad key problems would be 
fixed in an upcoming release. 

Bug.exe also contains the ability to 
send the command sets and keystrokes in 
a lexicon to either a printer or file. This 
helps in debugging complex lexicons. 

The bugu.exe program loads the Bug 
Computer with a lexicon and sets it up 
for voice recognition. Switches on the 
command line let you reset the Bug com¬ 
puter, turn voice recognition on or off, 
control microphone gain, and indicate if 
the system should beep on misrecognized 
words. Another switch lets you print out 
a summary of all the switches. The 
bugu.exe program does not remain 
resident in your computer’s memory, 
so it requires no extra memory. This 
makes the Bug system very easy on your 
memory. 

My word processing trials went very 


well. I created a lexicon with 16 common 
word processing functions (the same set 
used in my Covox test) and did 109 
trials. Of them, 44 trials (40 percent) re¬ 
sulted in no recognition and six trials 
(5.5 percent) resulted in misrecognition. 
However, 37 of those no recognitions 
were on the same word tried repeatedly, 
as were three of the misrecognitions. I 
retrained the words that gave me trouble 
and did another 77 trials. This time 13 
(16.8 percent) trials resulted in no recog¬ 
nition, and there were no misrecogni¬ 
tions. Again, nine of the no recognitions 
were the same word. Without that word, 

I had 64 trials with only four (6.25 per¬ 
cent) no-recognition errors. I also tried it 
with my printer going to simulate a noisy 
environment. I did 23 trials and had eight 
(34.8 percent) no-recognition errors and 
zero misrecognitions. 

I tried random words to see if I could 
get any misrecognitions. Saying “file” 
would cause “read file” to be recognized 
and “bold zoo” would cause “bold off’ to 
be recognized. But many other words did 
not cause any recognitions. 

I trained the numbers and symbols on 
a calculator as well. I had an occasional 
no-recognition error, but only one or two 
in about 100 commands. More signifi¬ 
cant was that I had to pause after each 
word: 1 -2-3-.-5-6-minus-1 -0-0-.-2-6. 

I found only one major problem with 
the software. You cannot use the pop-up 
menu software that comes with most 
types of mice. Bringing up the menu 
caused the system to go into a loop read¬ 
ing the last keyboard input. This hap¬ 
pened when the device driver was 
loaded, even if the Bug Computer was 
not doing voice recognition. Using the 


Enhanced laser printer output 


MicroLogic Software seems able to 
produce one excellent software utility af¬ 
ter another. Recently I reviewed, and 
raved about, LaserMenu ( Computer , 

April 1989, p. 88), an excellent utility for 
controlling a laser printer and similar to 
PrintMenu for dot-matrix printers. Then 
the company sent a copy of MoreFonts. 

It, too, is just what’s needed to squeeze 
out extra performance from your laser 
printer. 

MoreFonts is a font design and genera¬ 
tion system that allows you to develop 
endless combinations of stroke and style 
from the 14 included typefaces (such as 


Classic Serif, Tiempo, Standard Sans 
Serif, Geneva, Showtime, Burlesque, 
Opera, Poster, and Financial). You can 
make a typeface bold, outline, filled, 
oblique, italic, with or without a drop 
shadow, in portrait or landscape, with a 
point size from 2 to 999. And all of this 
is reasonably priced at $99.95. 

The details 

Following in the footsteps of the pre¬ 
vious utilities from MicroLogic Soft¬ 
ware, this application is menu driven 
with drop-down choices to 


mouse as a pointer (no keyboard input) 
worked fine. This is a known problem 
with a fix. In fact, technical support sent 
me a beta copy of the corrected device 
driver to demonstrate that it has been 
fixed. 

The Bug software was designed for 
CAD users. Nothing about the system 
limits its usefulness in other environ¬ 
ments, but the narrow focus seems to 
have colored the design of the user 
interface and the manual. I was told that 
they kept the interface and manual 
simple on purpose because they felt that 
their users would not be interested in ex¬ 
tra features (like changing colors) or sys¬ 
tem details (like what the bottom jack on 
the board is for or how the Bug Com¬ 
puter analyzes your voice or what the 
files on the disk are for). 

The ability of the Bug Computer to 
recognize spoken commands is impres¬ 
sive. It recognized most words after one 
training pass, although a few required 
two passes. Only one word consistently 
gave me trouble, and changing to a syno¬ 
nym fixed that. Some functionality and 
flexibility could be added to the soft¬ 
ware, and the manual could be expanded 
to give many more details. These limita¬ 
tions do not alter my opinion that the 
Bug speech recognition system is suit¬ 
able for use by the general population in 
a wide variety of applications. 

Contact Covox at 675 Conger St., Eu¬ 
gene, OR 97402, phone (503) 342-1271, 
and Command Corp. at 6045 Atlantic 
Blvd., Norcross, GA 30071, phone (404) 
662-1598. — N. Davids 

Voice Master: Reader Service 23 
Bug: Reader Service 24 


• “Select” a font and place it into a 
font set, 

• “Install” a font or font set, 

• “Download” a font or font set into 
your laser printer, and 

• exercise some “Options” related to 
the printer or font set. 

While the manual is well done and 
guides you through an example as well 
as a discussion of all the menu items, the 
on-line, context-sensitive help makes 
reading the manual unnecessary. In fact, 
the install procedure gives a short intro¬ 
duction for the user in a hurry to get the 
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system up and running without referring 
to the manual. 

MoreFonts supports all models of the 
Hewlett-Packard laser printer series 
(LaserJet as well as DeskJet). It is not 
copy protected and requires a compatible 
PC with 384 Kbytes and a floppy disk 
drive (a hard disk is recommended be¬ 
cause the generated fonts can take up a 
lot of space). Interestingly, MoreFonts 
includes fast and easy installation of both 
screen and printer fonts for Ventura Pub¬ 
lisher, PageMaker, Microsoft Word, 
WordPerfect, XYWrite, Ami, Excel, and 
Windows. That added plus integrates this 
package with all the applications that 
take advantage of my laser printer. 

I used MoreFonts with Ami ( Com¬ 
puter ■, June 1989, pp. 101-2) and Excel 


Product notes 

Port Lite — An Entry-level LAN 
System for personal computers is pro¬ 
duced by Waterloo Microsystems, 

3597 Parkway Lane, Suite 200, 
Norcross, GA 30092, phone (404) 
441-9252. Port Lite connects up to 
five IBM PS/2s, ATs, XTs, and com¬ 
patibles to form a PC LAN. Features 
include disk and printer sharing (five 
shareable disk drives and up to three 
printers per workstation), choice of 
DOS- or icon-based user interface, 
simplified network management, auto¬ 
matic power down protection (the data 
in transit may be lost after an unex¬ 
pected loss of power, but the file di¬ 
rectories and subdirectories will re¬ 
main intact), data backups with the 
DOS copy command or special 
backup icons for entire servers (also 
supports a conventional tape backup 
scheme), communication with another 
Port Lite LAN using a Port Lite Asyn¬ 
chronous Internet Gateway, and an 
upgrade path for a full Waterloo Port 
PC Network is available. 

Port Lite organizes the user’s work¬ 
space by assigning it an Office. The 
system manager assigns a user ID to 
each user on the network. Access to an 
Office is secured by a password. Each 
Office has icons to start programs. 
When starting a Port Lite Network 
Workstation, a Lobby screen is dis¬ 
played. The Entrance icon is used to 
log on to an Office. To log off and re¬ 
turn to the Lobby, use the Exit icon. 
Function key definitions in Port Lite 


running under Windows/386, with the 
Kyocera F-1000A printer ( Computer , 
April 1989, pp. 86-8). The HP-compat¬ 
ible Kyocera included 1.5 Mbytes of 
memory for downloading soft fonts. Us¬ 
ing Ami as a testbed for MoreFonts was 
quite easy because this graphic word 
processor uses Windows ability to down¬ 
load fonts and display a reasonable rep¬ 
resentation of the final results. 

Generating a 36-point font requires 
you to use the Select menu to specify the 
typeface, point size, fill pattern, outline, 
drop shadow, orientation, and symbol 
set. When you consider the number of 
choices, you realize how you could fill 
up your hard disk with all the possibili¬ 
ties. Next you use the Install menu to 
specify the application, printer type, and 


are displayed at the top of the screen. 
On-line help is available (F2). 

To set up the Port Lite LAN, you need 
the following items (not provided with 
this product): an Arcnet Network Inter¬ 
face card for each PC in the Port Lite 
LAN, cables (coaxial, twisted-pair, or fi¬ 
ber optic), an active or passive hub (for 
those using SMC PC/250 or PC/220 
Arcnet cards, hubs may not be required), 
and a DOS system diskette. Optional 
items on a Network Software Server 
(NSS) or Network Workstation (NW) are 
mouse and printer. 

Installation begins with the required 
hardware, then the Port Lite software for 
the NSS. You then install DOS and DOS 
applications, configure NWs, and finally 
perform system management tasks (setup 
user IDs, control up to 15 printers, create 
icons, back up files). The documentation 
is well written and easy to read. Port Lite 
costs $495. — M. Dediu 

N-Net 210 is a complete neural net¬ 
work development system for personal 
computers. In addition to the standard 
back-propagation model for supervised 
learning, N-Net supplies an algorithm for 
the functional-link net, a supervised 
learning model that enhances the input 
before it is presented to a simple network 
with no hidden layers. 

N-Net provides a powerful unsuper¬ 
vised learning algorithm based on Eu¬ 
clidean distance. It consists of the User 
Interface and the Programming Interface. 
The User Interface is an on-screen appli¬ 


screen display. MoreFonts then generates 
the necessary font for that particular ap¬ 
plication. Because you can choose a font 
set (made up of a collection of fonts), 
you can produce a number of font files 
that are linked to the application and 
stored in the proper subdirectories. 

An interesting option lets you store the 
description of the font rather than the bit¬ 
mapped font file. The option saves a 
great deal of memory, since the descrip¬ 
tion files are less than 100 bytes long 
rather than the tens of thousands of bytes 
needed for the bit-mapped files. The 
catch is that only MoreFonts can use 
these descriptors for downloading the 
font to the laser printer. 

Downloading a font with the Down¬ 
load menu provides a printer status indi¬ 


cation providing full-system functional¬ 
ity without requiring the user to write 
any programming code. The Program¬ 
ming Interface is a library of C functions 
that allows N-Net to be executed from C 
code or embedded in existing systems. 

N-Net 210 is based on the Functional 
Link Net architecture. This design pro¬ 
vides an integrated environment, where 
supervised learning, unsupervised learn¬ 
ing, and associative recall are all accom¬ 
plished within the same command and 
data structure, all within the same net. I 
found this important, because usually 
you must reconfigure the network when 
going from one type of learning algo¬ 
rithm to another. N-Net eliminates this. 

N-Net 210 is produced by AI Ware, 
11000 Cedar Ave., Suite 212, Cleveland, 
OH 44106, phone (216) 421-2380. The 
system requirements are an IBM PC-AT, 
PS/2, or compatible, DOS 2.0 or later, 
512 Kbytes of RAM, a hard disk with at 
least 2 Mbytes of available disk space, 
and Microsoft C version 5.0 or later (for 
the Programming Interface only). 

You can set the N-Net User Interface 
in four modes: system, edit, train, and 
consult. Each is represented as a menu 
and gives access to a specific set of func¬ 
tions. When N-Net is activated, the 
screen displays a system level window 
that remains as background in all modes 
at all times. This display is primarily a 
listing of all processes forming the neu¬ 
ral network system. At the top of the 
screen is the menu bar, which always 
shows “System,” “Edit,” “Train,” and 
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cation showing both the number of fonts 
loaded and the amount of printer mem¬ 
ory used. 

Finally, the Options menu allows you 
to reset the printer, specify the printer 
port, print a symbol set for a typeface, 
and make a metric file for installing a 
font into an application not supported di¬ 
rectly by MoreFonts. 

For all menus, Microsoft Mouse sup¬ 
port is provided. While this is handy, it 
really isn’t necessary because the on¬ 
screen prompts and logical choice of 
function keys make it very easy to navi¬ 
gate from menu item to menu item. 

Typical applications 

When I tested MoreFonts with Ami 


and Excel running under Windows/386, 
all I had to do for on-screen display was 
specify the font I wanted and then install 
it into the Windows environment. Instal¬ 
lation is actually automatic, consisting of 
updating the win.ini file for the new 
fonts. Excel and Ami then come up with 
new fonts already included in their font 
menus. The next step is to load the fonts 
into the laser printer. This is accom¬ 
plished by configuring the printer under 
Windows, specifically by selecting the 
“add fonts” item within the printer con¬ 
trol box. 

The printed results look very good in 
both applications. With 1.5 Mbytes of 
memory, my laser printer was quite ca¬ 
pable of accepting several soft fonts and 
still had room for pages of text and fig¬ 


ures. MicroLogic is currently preparing 
more than 40 additional typefaces corre¬ 
sponding to a superset of the “Postscript 
35” with selection of Adobe, Bitstream, 
or Compugraphic metrics and more than 
35 symbol sets. 

Even though I have been extremely 
pleased with my laser printer, there have 
been times when I wished for larger 
type. With the addition of MoreFonts to 
my list of indispensable utilities, I now 
have all that I wanted in a laser printer at 
an unbeatable low price. 

Contact MicroLogic Software, 6400 
Hollis St., Suite 9, Emeryville, CA 
94608, phone (415) 652-5464. 

— R. Eckhouse 

Reader Service 25 


“Consult” as menu items. Specific com¬ 
mand keys activate pop-up windows, 
which are menu driven. 

N-Net requires some good reading be¬ 
fore it can be used efficiently. It comes 
with two examples residing in two subdi¬ 
rectories. There are also three source 
code examples in appendix D for helping 
to learn the Programming Interface. The 
input data in the processes come from 
input pattern files. They must be loaded 
into an area of memory called the user 
data area. The user is responsible for al¬ 
locating sufficient memory for this user 
data area and later for deallocating it. 

The output result of training or consult¬ 
ing a process is formed in the output data 
area, created and managed by the sys¬ 
tem. The output data area can be stored 
in an output pattern file for later use. 

The various Programming Interface 
functions (about 150) available to the 
user can be grouped by functionality as 
follows: System and Process, Task, Nor¬ 
malizing, Functional Link, Supervised 
Learning, Unsupervised Learning, Patlist 
Routines, Associated Recall and Associ¬ 
ated Decision, System Error, and Filing 
Functions. Examples of Task functions 
are config_task(), which prepares the 
task for training, and get_no_of_layers, 
which returns the total number of layers 
in the task. 

The documentation is well written and 
detailed. At $1,495, N-Net 210 is a pow¬ 
erful neural network development sys¬ 
tem, useful in many practical 
applications. — M. Dediu 


Statistical analysis software is an im¬ 
portant analytical tool for many areas of 
business, government, and academia. 
SPSS Inc., 444 N. Michigan Ave., Chi¬ 
cago, IL 60611, phone (312) 329-3300, 
offers SPSS/PC+ V2.0, which is a family 
of products containing data entry, base 
statistical analysis, advanced statistics, 
trends, graphics, and reporting software 
(table, mapping, and Graph-in-the-Box) 
for the IBM XT, AT, PS/2, and com¬ 
patibles with 640 Kbytes of RAM and at 
least a 10-Mbyte hard disk. 

The SPSS/PC+ V2.0 Base Package, 
which is interactive data analysis soft¬ 
ware, contains all data, statistical, and 
file-handling routines; descriptive statis¬ 
tics; cross-tabulation tables and measures 
of association; categorical, correlation 
and regression analysis; analysis of vari¬ 
ance procedures; nonparametric tests; 
and report-writing and plotting functions. 

Other features are an optional menu 
mode for building commands, a context- 
sensitive help facility, and an on-line 
glossary of statistical and related terms. 

SPSS is a comprehensive and powerful 
statistical and information analysis sys¬ 
tem, useful for anyone who needs any 
type of basic statistical analysis. It costs 
$790. 

SPSS Data Entry II permits you to en¬ 
ter data, verify its accuracy, and edit data 
files. It is an integrated, interactive, 
screen-oriented data entry, data editing, 
and data cleaning tool. This program 
runs from DOS. If you have the Base 
Package, you can install it as a procedure 


fully integrated into the Base. It needs 
512 Kbytes of RAM. It costs $395. 

The Base Package is needed to run 
the following options: 

• SPSS/PC+ Advanced Statistics 
V2.0, which includes procedures for 
factor analysis, cluster analysis, hier¬ 
archical log-linear models, discrimi¬ 
nant analysis, multivariate analysis of 
variance, and reliability analysis of 
additive scales. Hardware require¬ 
ments are an IBM PC (and com¬ 
patibles) or IBM PS/2 with a 10- 
Mbyte or larger hard disk. It costs 
$395. 

• SPSS/PC+ Trends V2.0 lets you 
perform time series analysis and fore¬ 
casting, also for a price of $395. 

• SPSS/PC + Tables V2.0 displays 
and summarizes data and results for 
use in many tabular formats, from 
complex stub and banner, cross tabu¬ 
lations, and display of multiple re¬ 
sponse data, to frequency counts and 
descriptive statistics, with complete 
control over headers and labels. The 
price is $395. 

• SPSS/PC+ Graphics V2.0 con¬ 
tains the SPSS/PC+ Graph procedure 
and Microsoft Chart, which displays 
results in presentation-quality graph¬ 
ics. I found it practical and easy to 
use. The price is $395. 

The documentation for all these 
programs is detailed and well written. 

This family of products is very use¬ 
ful for almost any kind of statistical 
analysis you’ll need. — M. Dediu 
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NEW PRODUCTS 


Reverse engineering CASE for C on OS/2 


AutoCASE Technology has an¬ 
nounced Autoflow-C Version 2.0. Ac¬ 
cording to the company, the software can 
automatically generate structure charts 
and flowcharts from existing C source 
code. Version 2.0 includes automatic test 
coverage analysis. 

The Professional Edition can produce 
Postscript output for desktop publishing. 
It runs under OS/2 and DOS 3.0 or higher. 


Hypersoft claims that its Application 
Browser is the first VAX-based interac¬ 
tive tool for reverse engineering exist¬ 
ing applications. The software also 
automates the production of system 
documentation by generating graphic 
documentation describing the applica- 

Application Browser produces a 
graphic map of an application from the 
application’s source file. Arrow keys al¬ 
low users to move through the diagrams 
and switch to views of the code or textual 
description files. 


The virtual memory capability reputedly 
ensures almost unlimited chart size. 

Autoflow-C V2.0 requires a minimum 
of 512 Kbytes of system memory. It 
works with monochrome or CGA, EGA, 
or VGA-compatible displays. 

The Professional Edition of Autoflow- 
C V2.0 costs $499. 

Reader Service 30 


Graphic diagrams include perform 
charts, go-to charts, and call charts. 

Application Browser runs on Digital 
Equipment’s VAX computers under 
VMS with VT 100-compatible terminals 
or on IBM PCs or compatibles running 
MS-DOS. The software supports Cobol 
from VAX, DECsystem-10 and 20, and 
IBM mainframe machines. 

Prices start at $3,000 for the PC license 
and range from $5,800 for the MicroVAX 
II to $40,200 for the VAX 8840. 
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Wang enters PC- 
compatible market 

Wang Laboratories has entered the 
PC-compatible market with the intro¬ 
duction of three AT-compatible PCs 
and one Micro Channel Architecture- 
compatible PC. The company also of¬ 
fers MS-DOS 4.01 for the four systems, 
plus MS OS/2 Release 1.1, including 
Presentation Manager, for the AT- 
based systems. 

The PC 250/16 incorporates a 16- 
MHz 80286 microprocessor. The PC 
280/20 employs a 20-MHz 80286 
microprocessor. The PC 350/16S uses 
Intel’s 386SX microprocessor. The MC 
350/16S is an MCA-compatible system 
that relies on the 386SX CPU. 

The new PCs come in a variety of 
configurations. Pricing for base units 
including the CPU with 1 Mbyte of 
memory, a keyboard, a built-in disk 
controller, and a 1.2-Mbyte or 1.44- 
Mbyte disk drive starts at $2,095 for the 
PC 250/16, $2,995 for the PC 280/20, 
and $2,695 for the PC 350/16S. 

Prices for the MC 350/16S start at 
$2,995 for a system including the CPU, 

2 Mbytes of memory, a keyboard, and 
an on-board VGA 16-bit video 
controller. 
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Reverse engineering for Cobol on VAX 


Cipher provides backup for AS/400 systems 


Cipher Data Products offers a tape 
backup system for the IBM AS/400 
midrange computer. The Cipher 3830 
Series half-inch cartridge tape drive em¬ 
ploys the 3480-type cartridge. It comes 
in two models: the 3832 and the 3834. 
Both are available for the AS/400 mod¬ 
els B30 through B70. 

Cipher plans to market the drives 
through value-added resellers. VARs 
will set end-user pricing. 

According to the company, the 3834 
model can back up 500 Mbytes of data in 
as little as 11 minutes. It has a formatted 
data transfer rate of 896 Kbytes per 
second. 

The 3832 model reportedly transfers 
data at a rate of 448 Kbytes per second. 
Cartridges can be interchanged between 


the 3832 and 3834 for reading and writing 
data. 

The 3830 fits in 5.25 inches of vertical 
rack space in the AS/400. Two drives can 
be mounted next to each other in the AS/ 
400’s standard enclosure. 

According to Cipher, the 3830 is com¬ 
patible with the AS/400’s software. It at¬ 
taches to the system using IBM’s stan¬ 
dard 6110 magnetic storage device con¬ 
troller. 
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Cipher’s 3830 tape system for IBM’s 
AS/400 stores up to 570 Mbytes of data 
on each cartridge. 
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Prime software allows inspection during design 


Prime Computer claims that its series of 
software packages and software-worksta¬ 
tion combinations for coordinate measur¬ 
ing machines allow manufacturers to pro¬ 
gram CMMs to inspect parts while the 
parts are being designed. The CMM soft¬ 
ware from Prime’s Calma business unit re¬ 
portedly eliminates the need to build a 
prototype before designing inspection 
paths. 

The workstation-based packages, 
called CMM Feature One and CMM Sur¬ 
face One, combine the Calma CMM soft¬ 
ware and 3D design software with DN3500 
workstations from the Apollo division of 
Hewlett-Packard. The software-only ver¬ 
sions, called CMM Feature Two and CMM 
Surface Two, run on workstations from 
Apollo and Digital Equipment and include 
Calma 3D design software. 

The CMM packages feature off-line 
programming. 

, The CMM Feature One and Two pack¬ 
ages allow the creation of inspection paths 
on part features built with points, circles, 
cylinders, planes, lines, ellipses, spheres, 
and cones. The CMM Surface One and 
Two packages allow the creation of sur¬ 
face inspection paths for sheet metal, 
edges, slots, holes, and metal thickness 
compensation. 

Both surface and feature packages sup¬ 
port geometric dimensional tolerancing, 
multiple and movable coordinate systems, 
feature mirroring and duplication, and 


automatic feature recall. They also 
feature simulations of probe path move¬ 
ments, path replay, editing, and interro¬ 
gation; animation of machine motion to 
prevent probe collisions; control of pan, 
zoom, and viewing; and cycle time 
predictions. 

Calma CMM packages provide Dimen¬ 
sional Measuring Interface Specification 
1.2 and 2.0 support, interfaces for 3D sur¬ 
face scanning packages, feature program¬ 
ming for rotary tables, PH9 probe support, 
and dual-arm CMM support. 

The Feature One system costs $40,000 
and includes CMM software, 3D Prism/ 
DDM design software, and an Apollo 
DN3500 workstation with 8 Mbytes of 
memory, 8 color planes, a 60-Mbyte car¬ 
tridge tape drive, and a 348-Mbyte disk 
drive. 

The software-only CMM Feature 
Two costs $20,000 and includes CMM 
software and 3D Prism/DDM design 
software. 

The CMM Surface One package costs 
$46,000 for CMM software, surfacing 
software, 3D Prism/DDM software, and 
an Apollo DN3500 workstation with the 
same configuration as Feature One. 

The software-only Surface Two costs 
$26,000 and includes CMM software, sur¬ 
facing software, and 3D Prism/DDM de¬ 
sign software. 
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IBM adds new models to AS/400 family, tape systems 


IBM has announced new models in the 
Application System/400 family of com¬ 
puters, plus two new magnetic-tape stor¬ 
age systems and a new release of Operat¬ 
ing System/400. 

AS/400 Models B35 and B45 replace 
the B30 and B40 members of the 9406 
rack-mounted systems. The prices re¬ 
main the same. 

Model B35 reportedly increases per¬ 
formance up to 20 percent over Model 
B30. Main storage begins at 8 Mbytes 
and ranges up to 40 Mbytes. Model B35 
can have four workstation controllers 
and supports up to 16 communication 
lines and two local area network adapt¬ 
ers. It costs $27,820. The OS/400 pro¬ 
cessor-based charge is $14,700. 

Model B45 reportedly increases per¬ 
formance up to 20 percent over Model 
B40. It comes with up to six workstation 
controllers and supports up to 32 com¬ 
munication lines and two LAN adapters. 
It costs $65,620. The OS/400 processor- 
based charge is $26,250. 

The 3490 Models D31 and D32 Mag¬ 


netic Tape Subsystems and the 9348 
Model 1 Magnetic Tape Unit provide 
new storage options. 

The 3490 is a half-inch cartridge tape 
system featuring a data rate of up to 3 
Mbytes per second on 18 tracks, accord¬ 
ing to the company. The cartridge holds 
up to 200 Mbytes. The 3490 is compat¬ 
ible with the 3480 subsystem and uses 
the 3480 tape cartridge format. Model 
D31 is a single tape drive with its own 
integrated control unit and power sup¬ 
ply. It costs $53,250. Model D32 has an 
additional drive. It costs $79,900. 

The 9348 Model 1 Magnetic Tape 
Unit is a 1,600/6,250 bits-per-inch 
streaming tape drive that reportedly has 
an instantaneous data transfer rate of 
781 Kbytes per second with improved 
rewind time. It is rack-mounted, auto¬ 
threading, and auto-loading. Model 1 
costs $22,000. 

B35, B45: Reader Service 35 
D31, D32: Reader Service 36 
Model 1: Reader Service 37 


Grid Systems ships 
portable CD-ROM 

Grid Systems has begun shipping a 
portable CD-ROM drive designed to 
work with battery-powered laptop com¬ 
puters. The five-pound Model MXV-101 
Grid/Magnavox CD-ROM drive was de¬ 
veloped by the Northern Virginia Sys¬ 
tems Group of Magnavox Electronic Sys¬ 
tems and is sold under a joint marketing 
partnership between the two companies. 
Grid has agreed to refer customers to 
Magnavox. 

The drive is a 5.25-inch form factor, 
half-height CD-ROM drive incorporat¬ 
ing a SCSI interface. The drive costs 
$1,900 per kit, which includes the CD- 
ROM peripheral, the SCSI adapter car¬ 
tridge, and the associated software 
driver. 
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Software relies on DES to 
protect against viruses 

Enigma Logic’s Safeword Virus-Safe 
software lets users choose between Data 
Encryption Standard and ISO 8731-2 al¬ 
gorithms to protect their IBM PCs and 
compatibles against computer virus pro¬ 
grams. The software incorporates ANSI 
Standard X9.9 Message Authentication 
Code technology, according to the 
company. 

Safeword Virus-Safe uses encryption- 
based authenticators, which calculate 
digital signatures for those data files and 
programs selected for protection. Any 
modification of these programs report¬ 
edly triggers a change in the signature. 
Such a change is detectable by Safeword 
Virus-Safe’s Integrity Shell, Bootstrap 
Examination, or Sterile Kernel modules. 

Users can control the percentage of 
program or file bytes that will be en¬ 
crypted and summed. The remaining 
bytes are processed using a cyclic redun¬ 
dancy check. According to the company, 
this partial encyrption improves runtime 
performance. 

Users can check files at boot time or 
when they run them. The software sounds 
an alarm if protected files have been 
modified. When the software detects con¬ 
tamination, it allows users to ignore the 
change, accept the change and update the 
signature, or abort the attempt to use the 
modified file. 

Safeword Virus-Safe costs $1,050 for 
packages of 10 or $125 for single units. 
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Data General debuts Dashers 


Data General has announced a new 
family of PC workstations compatible 
with the IBM PC-AT under MS-DOS. 

The compact Dasher/286-12c, midrange 
Dasher/386SX, and high-end Dasher/ 
386-25 support Data General’s DG/PC-I 
networking software, CEO office auto¬ 
mation software, and other components 
of the company’s distributed computing 
line. 

The Dasher/286-12c measures 
12x15.5x3.75 inches. The base system 
includes a 3.5-inch, 1.44-Mbyte disk 
drive; two serial ports and one parallel 
port; built-in VGA video support; AT-in- 
terface disk adapters; disk controller; and 
two 16-bit I/O slots available for add-on 
cards. An internal 3.5-inch, 40-Mbyte 
drive is also available. The Dasher/286- 
12c costs $2,995 including hard disk 
drive. 

The Dasher/386SX comes with a 16- 
MHz Intel 386SX microprocessor, a 40- 


Mbyte internal disk drive, 2 Mbytes of 
memory (expandable to 8 Mbytes), VGA 
controller, 1.44-Mbyte disk drive, and 
keyboard. Both 40- and 100-Mbyte, 3.5- 
inch disk drives are available. The 
Dasher/386SX costs $3,795 with hard 
disk drive. 

The Dasher/386-25 incorporates the 
25-MHz Intel 80386 microprocessor. 

The base system includes a 156-Mbyte 
ESDI disk drive, 2 Mbytes of memory 
(expandable to 8 Mbytes on the system 
board and 16 Mbytes using a 32-bit mem¬ 
ory card), 5.25-inch disk drive, VGA con¬ 
troller, keyboard, and MS-DOS 3.3. The 
Dasher/386-25 with hard disk costs 
$8,495. 

A total of five half-height, 5.25-inch 
storage bays and eight I/O slots are in 
each system. A 150-Mbyte cartridge tape 
drive is available for tape backup. 
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33-MHz 386 sports a 32-bit cache controller 


Micro 1 has begun shipping a 33-MHz 
80386-based computer with an intelli¬ 
gent 32-bit disk cache controller. The 
Power 386-33 features a 128-Kbyte 
RAM cache and operates at 7.5 MIPS, ac¬ 
cording to the company. The intelligent 
cache controller uses an Intel AT/32-bit 
bus and a SCSI peripheral bus. An on¬ 
board 80376 microprocessor controls di¬ 
rect memory access and up to 4 Mbytes of 


RAM cache memory. 

A standard configuration includes sup¬ 
port for DOS, OS/2, and Xenix operating 
systems, Novell networks, and interac¬ 
tive Unix Version 3.2 networks. With the 
SCSI interface, users can add up to seven 
SCSI peripherals. 

The Power 386-33 costs $9,995. 
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Toshiba portable expands internally 


Toshiba America claims that its 
T3200SX is its most internally expand¬ 
able portable PC. The system features a 
16-MHz 80386SX microprocessor, six 
internal expansion slots, 13-Mbyte mem¬ 
ory capacity, VGA graphics display, and 
support for multiple operating systems, 
including MS-DOS and MS OS/2. 

The expansion slots include two IBM- 
compatible slots, one full-length and one 
half-length; a dedicated internal modem 
slot, and three memory card slots. 

The 1 Mbyte of RAM includes 640 
Kbytes of user memory and 384 Kbytes of 
extended memory. Memory is expand¬ 
able to 7 Mbytes in 2-Mbyte increments 
or 13 Mbytes in 4-Mbyte increments. 

The T3200SX has a 40-Mbyte hard 
disk drive with an average access time of 
25 ms, according to the company, and a 
1.44-Mbyte, PS/2-compatible, 3.5-inch 
floppy disk drive. 

The T3200SX measures 14.6xl5.6x 


3.9 inches and weighs 17 pounds. 

Standard features include a 91-key 
keyboard with separate cursor control 
and numeric keypad, 101-key keyboard 
port, selectable 25-pin parallel printer or 
5.25-inch external disk drive port, and 
two 9-pin RS-232-C serial ports. The sys¬ 
tem comes with MS-DOS 4.01. MS OS/2 
version 1.0 is optional, costing $325. 

The T3200SX comes with Quarter- 
deck’s Expanded Memory Manager-386 
(QEMM-386) and Multisoft’s PC-Kwik 
Power Pak performance utilities. 

The T3200SX costs $6,299. The 2- 
Mbyte memory modules cost $1,099. An 
internal 2,400 bps modem costs $349. 

The ToshibaLAN 15-bit card for Eth¬ 
ernet costs $699. An external 5.25-inch 
disk drive costs $499, while Floppy Link 
and Lap-Link Plus cost $199 and $129, 
respectively. 
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1C Announcements 


Company, Model, Function 


Burr-Brown 
ZPP1001; ZPP2001 
ADC; DAC 


Intel 

85C960 

PLD 


Linear Technology 

LTC1290 

ADC 


LSI Logic 
L64133 

Math coprocessor 


NCR 
53C700 
SCSI I/O chip 

Newbridge Microsystems 

CA34C168 

DEP 


Samsung Semiconductor 

KDA3310 

DAC family 


Standard Microsystems 
MSD95C10 Midas 
MCA interface 

Texas Instruments 
TACT83000 
386 PC chip set 


Texas Instruments 

TMS320C26 

DSP 


X24LC01/04/16 

EEPROMs 


Zilog 

Z16C00 

CPU 


Zymos 

System 90/SX 
386SX PC chip set 


Comments r.s. No. 


Analog-to-digital and digital-to-analog converters that interface directly with the AT&T WE 120 
DSP 16 and DSP32 microprocessors, respectively, with versions planned for the Motorola 
56000 and TI TMS320C25. Both have 16 bits of resolution with 14 bits of linearity. Sample 
rates to 150,000 samples/s. Cost: $300 for ZPP1001; $225 for ZPP2001. 

A programmable bus control programmable logic device. Provides address decoding, wait- 121 
state, and ready generation for systems using Intel’s 80960KA/KB embedded 32-bit micro¬ 
processors. Features on-chip burst-mode interface circuitry. Comes in a 28-pin plastic DIP. 

Cost: $11, $13, and $16.25 for 16, 20, and 25 MHz, respectively. 

A 12-bit version of the LTC1090 10-bit analog-to-digital converter. Includes a built-in multi- 122 
plexer, sample-and-hold function, and serial I/O communication function. Offers software- 
programmable functions, including software-controlled shutdown. Comes in 20-pin plastic or 
ceramic DIPs. Cost (100s): $15.95 (plastic). 

A single-precision, IEEE format, floating-point processor. Provides 33 Mflops of perfor- 123 
mance. Integrates separate multiplier and ALU units. Features two 32-bit input buses and a 
32-bit output bus, plus six 32-bit data registers. Operations take one cycle. Comes in a 144-pin 
ceramic PGA. Cost (100s): $382 (80 ns), $578.60 (60 ns). 

A SCSI I/O processor chip that controls data I/O between computer and peripherals without in- 124 
volving the CPU. Features a 32-bit DMA bus master, SCSI loop-back testing, bus signal conti¬ 
nuity checking, diagnostics, and external adaptability to EISA, MCA. Cost (1,000s): $48.70. 

A data encryption processor with a 150-Kbit/s throughput. Has 40 instructions to allow users 125 
to implement cryptographic protocols. Contains a 593-bit parallel math processor, an 8-bit 
microcontroller, an intelligent bus interface, two 256-bit write-only registers, a mask pro¬ 
grammable key, and error detection. Comes in a 40-pin package. Cost (100s): $175. 

Bipolar digital-to-analog converters with a sampling rate of 25 MHz and a linearity of 8, 9, and 126 
10 bits. Include on-chip data registers and do not require an external deglitcher. Work with 
video control inputs Sync, Blank, and Inverse. Come in 28-pin ceramic DIPs. Cost (100s): 

$18.15 for KDA3310J-8, $21.45 for J-9, $24.75 for J-10. 


A Micro Channel interface for disk access. Provides for handshaking signals required by the 127 
MCA bus and the serial interface logic for ESDI hard disk drives. Optimized to interface with 
the MSD95C01 disk controller. Comes in a 100-pin quad flatpack. Cost (5,000s): $20. 

A memory control unit, a data path unit, and an AT bus interface unit that provide the logic 128 
needed to produce 33-MHz PC-AT motherboards based on Intel’s 80386, 80386SX, or 80486 
processors. Each DPU provides a 16-bit path, so 32-bit systems need an additional DPU. Pro¬ 
duction planned for the fourth quarter. No prices given. 

A digital signal processor based on the TMS320C25 and pin-for-pin compatible. Features 129 
100-ns instruction cycle time, 1.5 Kbytes of on-chip RAM consisting of 16-bit words, on-chip 
boot ROM of 256 16-bit words, separate program and data buses, and DSP and general-pur¬ 
pose instruction sets. Production at the end of 1989. Cost (100,000s): $25 for 68-pin PLCC. 

Low-power EEPROMs with an operating range from 3-6V and ranging from low to high den- 130 
sity. X24LC01 (IK), X24LC04 (4K), and X24LC16 (16K) come in plastic DIP and surface 
mount packages over commercial, industrial, and military temperature ranges. They feature a 
serial interface and software protocol for operation on a two-wire bus. No prices given. 

A 16-bit real-time processor for embedded control applications. Has a RISC-like load/store 131 
architecture with hardwired control logic and nine basic instruction types. Features a Superin¬ 
tegration bus to add peripheral functions and a real-time register file. Includes 16 16-bit gen¬ 
eral-purpose registers and seven data types. Cost (1,000s): $9.60 for 10-MHz version. 

Supports the Intel 386SX microprocessor. Includes three VLSI devices: a peripheral 132 

coprocessor, an intelligent look-ahead memory, and an expansion bus interface chip. No 
prices given. 
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Microsystem Announcements 


Company, Model, Function Comments 


AST Research 
SixPak 286 
Memory board 


Beeco 

IPC-1000 

SBC 


Computer Boards 
CIO-AD16 

Data acquisition board 


Invisible Software 
Invisible RAM 
DOS extender 

MicroTouch Systems 

Unmouse 

Touch tablet 

Newer Technology 

Fastdrive 

Software 


Newer Technology 
4MB SIMM boards 
Mac memory boards 


Racal-Vadic 

9632PA 

Modem 

Radix Microsystems 
EPC-3 

Embedded PC family 


Soltec 

ADA-1000FE 

Data acquisition system 

Symbolics 

UX400S 

Coprocessor board 


Texas Microsystems 
Model 1448 
Industrial PC 


Themis Computer 

TSVME-133 

SBC 


A 16-bit memory board expandable to 4 Mbytes with 256-Kbyte or 1-Mbyte SIMMs. Supports 135 
expanded memory applications and has extended memory support for protected mode operat¬ 
ing environments. Features menu-driven, switchless installation and AST SuperPak utility 
software. Cost: $495 for 512 Kbytes, $1,145 for 2 Mbytes. 

An image-processing single-board computer containing a 68010 microprocessor. Features se- 136 
lection between eight camera inputs, real-time digital resolution of 512x512x8 bits, 16-bits- 
per-pixel image memory, I/O look-up tables, pipeline feedback with variable delay, and dedi¬ 
cated feature-extraction hardware. Cost: $8,995. 

A data acquisition and control board. Supports up to 16 channels of simultaneous sample and 137 
hold. Combines 24 bits of 8255 digital I/O register compatible with MetraByte’s PIO-12 and a 
12-bit, 16-channel, 100 KHz A/D, two D/A, and 8 bits of digital I/O typical of MetraByte’s 
DAS-16. Cost: $799 for 50K, $859 for 100K. 

A RAM software package that extends DOS memory up to 736 Kbytes in machines with Chips 138 
and Technologies’ shadow RAM. Also allows loading of up to 224 Kbytes of TSRs into 
shadow RAM. Works with the Neat Chipset and AT/386 Chipset. Cost: $39.95. 

A touch-sensitive glass tablet that replaces a mouse. Features a built-in function keypad for 139 
executing macro commands. Permits use of a stylus on the tablet surface. Works with Apple 
Macintosh II and SE computers. IBM version scheduled for the fourth quarter. Cost: $235. 

Allows users to set up 8 Mbytes of Mac OS memory and up to 24 Mbytes of nonvolatile RAM 140 
disk outside the standard OS environment. When set as the startup application, automatically 
loads all programs and files in its folder. Comes bundled with the company’s 4-Mbyte SIMM 
boards (see below). 

Memory boards for the Macintosh SE/30, II, IIX, and IICX. Come bundled with Fastdrive soft- 141 
ware (see above) and feature 1,024 refresh cycles per 16 ms. Typical current of 0.1-0.4A. TTL- 
compatible I/O. Cost: $945 for 7MM4MX8-8D (plastic; 32 1-Mbit chips); $995 for -8J (SOJ; 

32 chips, 4 Mbytes total); $2,395 for -10S (DIP-mount RAM; 4-Mbit chips). 

A full duplex, V.32 stand-alone modem with multiple speeds, asynchronous/synchronous 142 
operation, and leased-line and dial-up capabilities, plus diagnostics. Has Hayes AT dialing, 

MNP (Class 2-4) error correction and MNP (Class 5) data compression. Cost: $1,595. 

A line of embedded PCs in a rugged VMEbus form factor, with a CPU module measuring 143 

6x9x0.8 inches. Compatible with 386SX PC software. The CPU module includes up to 4 
Mbytes of DRAM, optional numeric coprocessor, serial I/O, parallel I/O, keyboard interface, 
and a VGA graphics controller, plus a VMEbus interface with system-controller functions. 

Cost (100s): $2,595 for CPU module with 1 Mbyte DRAM. 

Provides 2-120 channels of 50-ns, 10-bit data acquisition, with wide-band programmable dif- 144 
ferential amps and a 20-MHz, 80286 state machine interfacing to a PC-AT controller. Each 
analog channel has four digital channels and two over-range markers. Cost: starts at $13,275. 

A coprocessor board providing Sun workstation users with access to Symbolics’ Genera ob- 145 
ject-oriented software. An entry-level delivery system includes the board, 10 Mbytes of ECC 
memory, and Genera delivery software. Cost: $13,900; $21,900 for development system (with 
20 Mbytes of ECC memory). 

A PC Bus industrial workstation housed in an enclosure meeting NEMA 4 requirements to the 146 
panel level. Includes passive backplane architecture, speeds to 20 MHz, and a 14-inch multi¬ 
sync graphic display that functions with CGA, HDA, and EGA graphics boards. Variable con¬ 
figurations available. Cost: $7,350 for 12.5-MHz 80286-based PC with 1 Mbyte of RAM. 

A single-board computer based on a 25-MHz 68030 CPU with 68882 coprocessor. Has 512 147 

Kbytes of no-wait-state local memory; 1-4 Mbytes of shared memory; 512 Kbytes of dedicated 
SRAM Ethernet buffer; Ethernet, SCSI, floppy disk, and four-port multiprotocol serial lines; 
and a master/slave VSB port. Cost: $5,250 (with 4 Mbytes of RAM). 
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Fifth Annual Conference on COMPUTER ASSURANCE: 


SYSTEMS INTEGRITY, SOFTWARE SAFETY and PROCESS SECURITY 


CALL for PAPERS 


'ip a\ m'm 


COMPASS is dedicated to solving the problems of increasing 
computer assurance anti reducing the risk of safety, security 
anti economic disasters involving computer systems. The 
word "COMPASS" combines "COMPuter" anti "ASSurance." 
Computer assurance includes process security, systems and 
software safety, tpiality assurance and control, reliability, 
formal verification anti validation, ami systems engineering. 
The other engineering disciplines, physics, mathematics anti 
human factors also play a rtde in computer assurance. All 
these are vital for the assurance of transportation, medical, 
manufacturing, financial, telecommunications, defense and 
other critical computer controlled systems. 

Papers ami panel proposals should address 
research, other accomplishments or issues. 
Double-spaced, single-sided submissions only . 



IEEE 


Submissions Due: 

Acceptance Notices: 
Conference Dates: 


December 12, 1989 
February 15, 1000 
June 20 - 20, 1000 


Place: National Institute of Standards anti Teclmology 
Gaithcrsburg. Mb (Suburban Washington. HI ) 

COMPASS sponsors: IEEE Aerospace tP Electronics Society 
IEEE National Capital Area Council 


INFORMATION: 

General Chair: Oolores Wallace 

National Institute of 
Standards anti Technology 
E-MAIL: 

wallace@swe.ncsl.nist.gov 
PHONE: (301) 975-3340 


SEND PAPERS TO: 

Program Chair: II.O. Luhhes 

13313 Taney Orive 
licitsvilie. MO 30705 
E-MAIL: 

lublies@ittLnrLnavY.niil 
PHONE: (303) 404-7337 
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Conference speakers to focus on supercomputing’s future from 3 aspects 


Edmund L. Gallizzi 

John Rollwagen, Alvin Trivelpiece, 
and Gary Smaby will present invited ad¬ 
dresses focused on the future of super¬ 
computing from three different perspec¬ 
tives when they appear at Supercom¬ 
puting 89 November 13-17 in Reno, Ne¬ 
vada. 

The conference is being sponsored by 
the IEEE Computer Society’s Technical 
Committees on Supercomputing Appli¬ 
cations and Computer Architecture and 
the ACM. R. Ron Bailey of NASA Ames 
is the general chair, and Gary Johnson of 
the San Diego Supercomputing Center is 
the program chair. 

The growth of semiconductor technol¬ 
ogy, the development of parallel com¬ 
puter architectures, the emergence of 
customer and user needs, and the entry of 
new and traditional vendors into the su¬ 
percomputer marketplace has generated 
a growing and changing supercomputing 
environment. As an indication of the 
changes, about half of the approximately 
40 vendors listed in the conference’s ad¬ 
vance program are manufacturers of tra¬ 


ditional or parallel “supercomputer” 
architectures. 

Strangely missing from the list is CDC/ 
ETA, which had an important presence at 
last year’s Supercomputing conference 
and, with its CDC6600 in the mid-1960s, 
was the first supercomputer manufac¬ 
turer. However, during the past year, 
CDC/ETA withdrew from the supercom¬ 
puter market. 

Supercomputing 89 is taking place on 
the eve of the 1990s, which will probably 
be the decade of the supercomputer. Each 
of the speakers is uniquely qualified to 
speak about his sector of the supercom¬ 
puting community. 

In the keynote address, Rollwagen, 
chairman and CEO of Cray Research, will 
speak on global supercomputing devel¬ 
opments in 1989 and the future of the in¬ 
dustry in the 90s. Rollwagen has been 
with Cray since 1975 and is largely re¬ 
sponsible for ensuring a fluid corporate 
environment to foster individual creativ¬ 
ity. 

Trivelpiece, director of Oak Ridge Na¬ 


tional Laboratory and vice president of 
Martin Marietta Energy Systems, will be 
the banquet speaker and will discuss the 
past, present, and future of information 
processing. His ORNL activities include 
research and engineering development in 
the areas of fusion, fission, and conserva¬ 
tion as well as managing a staff of 5,000 
and a budget of $500 million. 

Smaby, president of a Minneapolis- 
based consulting, research, and financial 
advisory firm bearing his name that 
serves technology companies involved in 
high-performance computing, will give 
the luncheon address. His topic will be 
“Supercomputing — A View from Wall 
Street.” 

Other conference events will include a 
wide variety of tutorials, an extensive 
technical program, research and vendor 
exhibits, the Visualization Theater, and 
the 20th Annual ACM North American 
Computer Chess Championship. 

For conference registration informa¬ 
tion, contact Lyz Dunham, MS 258-6, 
NASA Ames Research Center, Moffett 
Field, CA 94035, phone (415) 694-4370. 


Design automation’s growth from IC to system-level design tools seen 


Edmund L. Gallizzi 


“Competitors who have adopted de¬ 
sign automation are now winning sub¬ 
stantial victories in the marketplace at the 
expense of those who haven’t.” So said 
Gerard H. Langeler, founder, president, 
and chief operating officer of Mentor 
Graphics, in depicting the current state of 
design automation when he keynoted the 
26th Design Automation Conference 
June 26 in Las Vegas. 

The June 25-28 event was sponsored 
by the IEEE Computer Society and ACM, 
with Donald E. Thomas of Carnegie Mel¬ 
lon University serving as the conference 
chair and Richard Newton of the Univer¬ 
sity of California at Berkeley as the pro¬ 
gram chair. 

DAC 26 also featured 45 technical ses¬ 
sions, six panel discussions, and, on June 


29, six full-day tutorials. The proceed¬ 
ings, order No. 1961, is available from 
the Computer Society Press, Los Alami- 
tos, California, by calling (800) CS- 
BOOKS or (714) 821-8380 in California. 

Looking back and ahead. Langeler’s 
talk, entitled “Electronic Design Auto¬ 
mation Comes of Age: Development 
Over the Last 10 Years, Directions Over 
the Next 10 Years,” looked back 10 years 
to the 16th DAC chair’s message by 
David Hightower of Texas Instruments. 
Hightower stated that there were no sys¬ 
tems that allowed “logic in” and “silicon 
out” for integrated circuits. 

According to Langeler, “Parallel ad¬ 
vances in design automation and ASIC 
(application specific integrated circuit) 



Jerry Langeler was the keynote 
speaker at DAC 26. 
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technology now allow engineers to rou¬ 
tinely produce chips that function cor¬ 
rectly at first silicon.” 

Langeler identified four major groups 
from the diverse community of design 
automation users. 

• The “inexperienced innovators” are 
companies, often startups, prepared to 
take high technological and financial 
risks, who want the most innovative tools 
at very reasonable prices. 

• The “experienced innovators” have 
focused needs with previous engineering 
experience and want specific tools that 
can be integrated into their existing de¬ 
sign environments. 

• The “experienced conservatives” 
have previous engineering experience 
and are prepared to a pay a premium price 
for a well-proven total system solution. 

• The “inexperienced conservatives” 
are generally satisfied with the more tra¬ 
ditional engineering approaches but will 
look to design automation when pushed 
by erosion in their competitive advan¬ 
tage. 

Lessons learned. Langeler said sev¬ 
eral lessons have been learned from the 
past 10 years of design automation devel¬ 
opment, including “It takes time for de¬ 
sign automation technology to be ac¬ 
cepted,” “Trust is seldom instantaneous 
and mostly cumulative in nature,” “De¬ 
sign automation may act as a gateway to 
new methodologies, but it cannot do so at 
the expense of existing ones,” and “There 
is no such thing as the ‘typical engineer’ 
working on the ‘average design.’ ” 
Langeler used these lessons to prognosti¬ 


cate the future. 

In the next decade, the successful IC- 
level design tools will grow to system- 
level design tools while continuing to 
provide and extend the IC design role that 
has become critical to the electronics in¬ 
dustry, the speaker said. 

Additionally, the next decade will see a 
move to open design automation archi¬ 
tectures that will provide a framework of 
generalized functions like design man¬ 
agement, decision support, database ac¬ 
cess, and user interface, he said. The vari¬ 
ous specific design automation tools nec¬ 
essary for the task can be placed into this 
framework. This integration requires the 
development of broader standards. “By 
1990, at the system level there will be less 
difference between mixed sets and 
matched sets of design automation 
tools.” 

The business structure of the design 
automation industry will change with the 
consolidation of vendors, in part because 
of the move to system-level tools, 
Langeler said. The trend will be “toward 
fewer and larger design automation ven¬ 
dors that offer very broad and deep solu¬ 
tions.” But Langeler expects plenty of 
niche opportunities for small companies. 

Messages delivered. Langeler deliv¬ 
ered messages to the various members of 
the design automation community. 

To inhouse developers, he suggested 
they keep a tight focus on their needs and 
not duplicate what the vendors provide. 
The move to openness will make it easier 
to integrate inhouse-developed tools. 

But the proliferation tools from vendors 


“will continue to reduce the number of in¬ 
stances where proprietary tools make 
sense.” 

To universities, he pointed out that the 
unrestricted flow of design automation 
technology from universities has ended 
and all product development is now done 
in the commercial sector. Thus, the mes¬ 
sage is to “take the high ground” and 
“provide the theoretical framework for 
the development of new tools and explore 
radical new approaches to new prob¬ 
lems.” 

The keynoter said the message to com¬ 
mercial design automation vendors is 
simple. “You must immediately make a 
decision whether to become a broadline 
supplier or niche supplier,” he said. 
“There is an optimistic note here for niche 
players: When the current wave of merg¬ 
ers and acquisitions ends, their long-term 
role in the market will be much better de¬ 
fined, allowing them to develop better 
business strategies.” Additionally, the 
vendors will need “deep pockets” to sur¬ 
vive the 1990s because of thin profit mar¬ 
gins. 

To engineering departments, Langeler 
said “The message is very clear: If you 
haven’t adopted design automation yet, 
you better start today or risk a very se¬ 
vere, if not fatal, competitive handicap.” 
He suggested that increasingly inte¬ 
grated tools may require organizational 
changes in companies to allow the use of 
tools that transcend the typical organiza¬ 
tion barriers between circuit design, 
physical layout, software design, pack¬ 
age design, product test, and documenta¬ 
tion. 


‘Why Simulation Works’ to be Pritsker’s WSC 89 keynote topic 

Barry L. Nelson, Ohio State University 
Philip Heidelberger, IBM Research Division 


A. Alan B. Pritsker will deliver the key¬ 
note address, “Why Simulation Works,” 
when the 1989 Winter Simulation Con¬ 
ference convenes December 4-6 in Wash¬ 
ington, DC. 

Kenneth J. Musselman of Pritsker Cor¬ 
poration is the general chair of WSC 89, 
and Philip Heidelberger of the IBM Re¬ 
search Division is the program chair. The 
IEEE Computer Society and the Society 
for Computer Simulation are among the 
organizations sponsoring the event. 

Pritsker is an adjunct professor at Pur¬ 
due University and a member of the Na¬ 
tional Academy of Engineering as well as 
chairman of Pritsker Corporation. He has 
made important contributions to simula¬ 
tion methodology, languages, education. 


and the widespread acceptance of simula¬ 
tion in industry, and has developed or 
codeveloped many simulation lan¬ 
guages, including SLAM II. 

The focus of WSC 89 will be discrete 
event, stochastic simulation. The confer¬ 
ence will feature tutorials and research 
sessions on a broad spectrum of topics: 
software, modeling and analysis tech¬ 
niques, and applications of simulation in 
manufacturing, computer, communica¬ 
tions, military, and health care systems. 

A session on simulating high-perfor¬ 
mance computer systems, including 
simulation of processor pipelines and 
cache memory systems, promises to be of 
special interest to computer scientists. 
Two sessions will be devoted to speeding 


up simulations of rare events, such as fail¬ 
ures in highly dependable computer sys¬ 
tems or buffer overflows in communica¬ 
tions networks. 

WSC 89 will feature the role of simula¬ 
tion in computer integrated manufactur¬ 
ing. One session will be devoted to inter¬ 
facing simulation models with computer¬ 
ized factory control software for debug¬ 
ging the control software and improving 
the control algorithms. Other manufac¬ 
turing-related sessions will deal with 
evaluating scheduling policies in com¬ 
plex manufacturing systems, including 
semiconductor manufacturing. 

WSC 89 will also examine the many 
possibilities for integrating simulation 
and artificial intelligence. For example, 
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one session will explore the use of AI 
techniques, including object-oriented 
programming, to develop and manage the 
development of complex simulation 
models. Papers in other sessions will de¬ 
scribe how expert systems and simula¬ 
tion can be used jointly to model and to 
improve scheduling and control policies 
in manufacturing systems. 

Discrete event simulation in parallel 
computing environments is another 
theme of this year’s conference, with a 
state-of-the-art tutorial plus sessions de¬ 
voted to the theory of parallel simulation, 
testbeds for building and evaluating par¬ 


allel simulation experiments, and the re¬ 
sults of actual implementations. 

WSC 89 will include an extensive 
schedule of tutorials at introductory and 
advanced levels presented by leading re¬ 
searchers and software developers. The 
introductory tutorials will cover the fun¬ 
damentals of discrete event simulation 
for audiences with no previous back¬ 
ground in simulation. The more ad¬ 
vanced tutorials are designed for re¬ 
searchers and practitioners who want to 
learn about the state of the art in emerging 
topics, such as parallel simulation and 


simulation optimization techniques. 

Also on the agenda are a preconference 
PhD student colloquium and a postcon¬ 
ference tour of the National Institute of 
Standards and Technology’s Advanced 
Manufacturing Research Facility. 

To obtain a copy of the WSC 89 pre¬ 
liminary program, including a list of the 
speakers and sessions plus registration 
and hotel reservation information, con¬ 
tact Barry L. Nelson, Department of In¬ 
dustrial and Systems Engineering, Ohio 
State University, Columbus, OH 43210, 
phone (614) 292-0610. 


Medical symposium looks at regulation of computer-based systems 

Margaret Peterson, University of Connecticut 


The regulation and approval process 
associated with the safety and reliability 
of computer-based medical instruments 
was a key topic addressed throughout the 
second IEEE Symposium on Computer- 
Based Medical Systems, held June 25-27 
in Minneapolis. 

James Howard of General Electric and 
consultant Ruth Dayhoff served as the 
keynote speakers, with Howard focusing 
on “Computer-Based Medicine: The Op¬ 
portunity and the Challenge” and Dayhoff 
on “Software Quality: The Problem of 
Proof.” 

Timothy J. Kriewall of Sams/3M 
served as Symposium Committee pro¬ 
gram chair. The IEEE Computer Society, 
IEEE Engineering in Medicine and Biol¬ 
ogy Society, and University of Minnesota 
sponsored the event. 

The proceedings, order No. I960, is 
available from the Computer Society 
Press, Los Alamitos, California, by call¬ 
ing (800) CS-BOOKS or (714) 821-8380 
in California. 

Keynote remarks. Howard described 
the evolution of regulations, safety, and 
hazards from the early X rays, with their 
oft-tragic consequences for operators, to 
one of the latest developments, nuclear 
magnetic imaging. 

In his discussion of the procedures nec¬ 
essary to acquire Food and Drug Admini¬ 
stration approval for the sale of medical 
instruments, Howard pointed out that fea¬ 
tures can now be modified by changing 
software, not hardware. The approval pro¬ 
cess concentrates on paperwork and often 
tends to increase cost, he said. 

In the second keynote address, Dayhoff 
summarized the history of software devel¬ 
opment practices over the past 25 years, 
leading to current multiuser systems im¬ 


plemented with microprocessors. 

As an example of computer-system 
problems, Dayhoff noted the recent disas¬ 
ter in which an airliner was destroyed by a 
missile controlled by the Aegis ship de¬ 
fense system. She said much of the re¬ 
sponsibility for the incident was placed on 
misinterpretation of data the computer 
system presented to operators, who were 
working in a high-stress environment that 
included high temperatures and humidity. 
The Aegis computer system was never 
tested for user panic under stress, said 
Dayhoff. 

Speakers, tutorials. John Long of the 
Department of Surgery at the University 
of Minnesota addressed the symposium 
on “Automation and the Healing Arts: The 
Changing World of Medicine in the Infor¬ 
mation Age.” 

At one point in his talk. Long asked, 
“Who controls medicine: the physician, 
the patient, the government, the insurance 
company?” He said there is an ongoing 
struggle between the art, the science, dig¬ 
nity, and privacy versus the need to know. 
Long stressed that whoever interprets a 
computer result must understand the sys- 

Richard Fries and Raymond Riddle of 
Nicollet Instrument presented a tutorial 
on “Medical Device Reliability and 
Safety.” Fries opened with a very clear 
message: “Reliability is an attribute you 
have to design for, plan for, and build in.” 

Reliability is the probability that the 
product will perform a required function 
without failure under stated conditions 
for a specified period of time, Fries said. 
Quality does not include a time frame, but 
reliability does. Although a prototype can 
be reliable, the manufacturing process 
must also be reliable. Additionally, there 


must be a long enough “bum-in” period, 
that is, a chance to test for reliability. 

Frank Houston of the FDA and attorney 
Donald J. Stone presented a tutorial en¬ 
titled “Regulatory Issues and Standards.” 
Stone addressed performance standards 
and their difference from regulatory stan¬ 
dards. FDA standards are mandatory; 
IEEE standards are performance stan¬ 
dards. It is common to put safety regula¬ 
tions under performance standards, he 
said. 

The approval method for the sale of one 
class of medical instruments was dis¬ 
cussed at many of the symposium’s 
events. The approval method, sometimes 
referred to as 510, is for instruments that 
are more complex than the simplest de¬ 
vices, like tongue depressors, and yet are 
less complex than the largest, class III, 
medical instruments. The 510 approval is 
acquired by filing a notification with the 
FDA that shows the device to be similar to 
already approved devices. 

Stone described a regulation problem 
on which the FDA is currently “evaluating 
its position.” To outline the problem, 
Stone said that a computer system, includ¬ 
ing software and hardware, used to main¬ 
tain medical records would not require 
approval for sale if the data was input via a 
terminal interface by an operator. How¬ 
ever, if the same system was directly con¬ 
nected to medical equipment that required 
approval, the record-keeping system 
would also require approval, even if the 
record-keeping system was a totally pas¬ 
sive part of the system. The FDA is wor¬ 
ried about “unintentional interactions.” 

Next year’s symposium will be held 
from June 3-5 in Chapel Hill, North Caro¬ 
lina. H. Troy Nagle of the Electrical and 
Computer Engineering Department at 
North Carolina State University will 
serve as symposium chair. 
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Congress 89 keynoter calls for improvements in blending theory, practice 

Edmund L. Gallizzi 


“The best theory is inspired by prac¬ 
tice, and the best practice is inspired by 
theory.” That was the message Donald 
Knuth of Stanford University delivered 
when he, sharing the keynote-speaker 
podium with John Young of Hewlett- 
Packard, addressed the 11th IFIP World 
Computer Congress August 28. 

Young, president and CEO of HP, pre¬ 
sented a talk entitled “Standards and the 
Computer Industry: History in the Mak¬ 
ing” at the San Francisco event, which 
continued through September 1. 

The International Federation for Infor¬ 
mation Processing, which has 46 member 
societies representing 59 countries, 
sponsored the event. One of IFIP’s mem¬ 
ber societies is the American Federation 
of Information Processing Societies 
(AFIPS), of which the IEEE Computer 
Society and 10 other technical and pro¬ 
fessional societies are members. This 
year’s Congress 89 was the first held in 
the United States in 24 years. 

Stephen S. Yau of the University of 
Florida was the Organizing Committee 
chair, and Herve Gallaire of the European 
Computer-Industry Research Centre in 
the Federal Republic of Germany was the 
Program Committee chair. 

Conference theme. In keeping with 
the conference theme of “Better Tools for 
Professionals,” Knuth said that “the best 
way to improve our tools is to improve the 
ways we blend theory and practice.” 

In his introduction, Knuth suggested 
that icons, graphical representations of 
information, “have become so pervasive 
that I think people might soon be calling 
this place Silly Icon Valley.” 

He used the icons of a light bulb and a 
hand carrying a briefcase to represent 
theory and practice, respectively. With a 
little personal reflection, Knuth de¬ 
scribed the blend of theory and practice 
that caused him to be “attracted to com¬ 
puter science because its theory seemed 
much more exciting and interesting to me 
than the new mathematical theories I was 
hearing about in the 60s. 

“I noticed that computer science the¬ 
ory not only had a beautiful abstract 
structure, it also answered questions that 
were relevant to things I wanted to do. So I 
became a computer scientist. 

“One of the main reasons I’ve chosen to 
speak about theory and practice today is 
that I’ve spent the past 12 years working 
on a project that has given me an unusual 
opportunity to observe how theory and 
practice support each other.” That proj¬ 
ect led to the development of Tex, a sys¬ 
tem for typesetting, and Metafont, a sys¬ 


tem for generating alphabets and sym¬ 
bols. 

Examples support thesis. Knuth pre¬ 
sented several examples from the devel¬ 
opment of Tex and Metafont to support 
his thesis of the importance of blending 
theory and practice. His first example 
was a method for the hyphenation of 
words developed by a student of his, 
Frank Liang. 

“The beauty of Liang’s method is that it 
is highly accurate, it runs fast, and it takes 
up very little space inside a computer. 
Moreover, it works with all languages, 
not just English.” The method works by 
representing “hyphenation rules by a set 
of patterns, where each pattern is a string 
of letters separated by numerical values.” 
The possible hyphen locations are found 
by finding all the patterns that appear as 
substrings of the word to be hyphenated. 
Once the matching patterns are found, the 
maximum of all the numerical values are 
calculated. If the calculated value is odd, 
then the word may be broken between 
those strings. Sets of patterns have been 
found for French, German, Italian, Span¬ 
ish, Portuguese, Swedish, Icelandic, 
Russian, and other languages. 

“Liang discovered this unified method 
only after considerable theoretical study 
of other techniques, which solved only 
special cases of the problem. And his 
practical work also had a theoretical pay¬ 
off, because it led him to discover a new 
kind of abstract data structure called a 
dynamic trie.” 

A lesson learned. One of the lessons 
Knuth learned from the development of 
the typesetting system is that “software is 
hard.” 

“During the past decade I was sur¬ 
prised to learn that the writing of pro¬ 
grams for Tex and for Metafont proved to 
be much more difficult than all the other 
things I had done (like proving theorems 
or writing books). The creation of good 
software demands a significantly higher 
standard of accuracy than those other 
things do, and it requires a longer atten¬ 
tion span than other intellectual tasks.” 

In warning about imbalances of sup¬ 
port for theory and practice, Knuth said, 
“When theory becomes inbred — when it 
has grown several generations away from 
its roots, until it has completely lost touch 
with the real world — it degenerates and 
becomes sterile.” 

Later he stated, “The past decade has 
witnessed a very unfortunate trend in the 
pattern of funding for basic, theoretical 
research.” In the past, the funding had 


been well balanced between the theory 
and the practice. “But, in recent years, an 
even greater amount of research dollars 
have been switched away from basic re¬ 
search and earmarked for mission-ori¬ 
ented projects. 

“At the present time, the scientific 
community faces a crisis in which a sub¬ 
stantial number of the world’s best scien¬ 
tists in all fields cannot get financial sup¬ 
port for their work unless they subscribe 
to somebody else’s agenda telling them 
what to do. We need a balance between 
theory and practice in the budgets for sci¬ 
entific research.” 

Challenge issued. In closing, Knuth 
said, “I would like to say something 
memorable, something of value, some¬ 
thing that you might not expect to hear. I 
thought about David Hilbert’s famous 
address to the International Congress of 
Mathematicians in 1900 when he pre¬ 
sented a series of problems as challenges 
for mathematicians of the 20th century. 
My own goals are much more modest than 
that; but I would like to challenge some of 
you in the audience to combine theory 
and practice in a way that I think will have 
a high payoff. 

“My challenge problem is simply this: 
Make a thorough analysis of everything 
your computer does during one second of 
computation.” Knuth suggested several 
questions that should be answered about 
the computation made in the randomly se¬ 
lected second. The questions are: “Are 
the programs correct or erroneous?” “Do 
the programs make use of any nontrivial 
theoretical results?” “Would the pro¬ 
grams be substantially better if they made 
more use of known theory?” “Can you 
devise new theoretical results that would 
significantly improve the performance of 
the programs during the second in ques¬ 
tion?” 

“In conclusion, let me encourage all of 
you to strive for a healthy balance be¬ 
tween theory and practice in your own 
lives,” Knuth said. 

The key to growth. In his keynote ad¬ 
dress, Young said standards hold the key 
to the growth of the computer industry. 

He also likened today’s outlook in the 
computer community to that of the auto¬ 
mobile industry eight decades ago when 
it was at the dawn of its growth explosion. 
At the turn of the century, only a few 
people had cars, but, by 1915, standards 
appeared that described the mechanisms 
for steering, speed control, brakes, etc. 
And, in the following decade, the market 
doubled. 
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Young introduced his address by look¬ 
ing back to 1965, the last time the Con¬ 
gress was held in the United States, and 
describing the hot issues or questions of 
that time. He then identified his top candi¬ 
dates for the questions of this decade as 
“How can computer vendors respond to 
the growing clamor for industry stan¬ 
dards while, at the same time, competi¬ 
tively differentiate themselves from their 
competitors?” Or “to put the question on a 
more personal level: How can computer 
scientists reconcile the seemingly diver¬ 
gent goals of standardization and innova¬ 
tion?” He said standards are inevitable 
“quite simply because computer custom¬ 
ers have finally begun to revolt.” 

Productivity decline. In a surprising 
statement he said, “It’s discouraging to 
see that in the US, and I suspect the same 
may be true elsewhere, ‘white collar’ pro¬ 
ductivity actually has declined since the 
mid-1960s.” 

He noted that that is “kind of an indict¬ 
ment of computers” because “the bulk of 
investments in information technology 
have been in the service sector — in those 


industries that employ most of the white 
collar workers. 

“In fact,” he said, “the service indus¬ 
tries that have invested most heavily in 
computing technology are the ones with 
the very worst productivity records. This 
unhappy correlation hasn’t gone unno¬ 
ticed by computer customers.” 

The demands “to increase productivity 
and build a nationwide information infra¬ 
structure point to the need for what we at 
Hewlett-Packard call a cooperative com¬ 
puting environment.” This environment 
is supported by “a network of heterogene¬ 
ous computers that can work together as if 
they were a single integrated whole.” 

This approach to computing requires 
standards that lead to two prime ques¬ 
tions, he said: “What do we mean by stan¬ 
dards in the computer industry?” and 
“How will standards affect the ability of 
computer scientists to innovate and com¬ 
puter vendors to differentiate themselves 
from their competitors and still be com¬ 
pliant with standards?” 

Young said “we have nothing to fear 
from standards. They are constructive 
constraints. Standards don’t just con¬ 


strain us; they empower us.” 

With respect to the specifics of stan¬ 
dards, Young enumerated the following: 
“First, we should standardize in a way 
that is independent of specific systems or 
applications. Second, what should be 
standardized depends on the maturity of 
the technology involved. Third, user 
needs and preferences have to be consid¬ 
ered. Fourth, we need to have the appro¬ 
priate organizations in place to support 
the standard throughout its entire life 
cycle. And fifth and finally, the standards 
must be open.” 

By open Young said he meant that “the 
standards should be freely available to all 
computer vendors, the licensing terms 
should be reasonable and stable, develop¬ 
ers should have early and equal access to 
specifications, and technological inputs” 
to support the standard’s development 
should be actively solicited “from a wide 
variety of sources.” 

Young closed by reminding the audi¬ 
ence that “the computer industry has 
come of age, but that we are by no means a 
mature industry” and “much remains to 
be done.” 


Earn a Blue Ribbon 
at Our Tools Fair 

If you have a tool — whether commercial 
or research — for software developers, 
IEEE Software would like to consider it 
for its Tools Fair issue in May 1990. 
Today’s software practitioner has thou¬ 
sands of tools to choose from. This issue 
will help him narrow his options. We 
seek descriptions of top-notch tools for 
software developers and managers. 

Descriptions are limited to 1,000 words and must be 
received by Dec. 15,1989. An entry form must accom¬ 
pany decriptions. For a form, write Paul Oman, Com¬ 
puter Science Dept., University of Idaho, Moscow, ID 
83843, or call (208) 885-6589. 

For advertising information, write IEEE Software, 
10662 Los Vaqueros Cir., PO Box 3014, Los Alamitos, 
CA 90720-1264, or call (714) 821-8380. 

Software 

The state of the art 
about the state of the practice. 


ANNOUNCEMENT AND CALL FOR PAPERS 

Al, SIMULATION AND PLANNING IN HIGH AUTONOMY SYSTEMS 
March 26-27,1990 

Sponsoring Agencies: The University of Arizona, College of Engineering and Mines 
Department of Electrical and Computer Engineering, Martin Marietta Data Systems and 
McDonnell Douglas Corporation. 

In Cooperation With: AT&T, Bell Canada, Information Machines, 

NASA-Ames Research Center, Rand Corporation and Siemens Corporate Research. 
Increasing the autonomy of systems in automation and robotics is a key element in 
system engineering with such goals as: 

—reducing the need for human intervention and supervision in remote or hazardous 
environments. , . 

—relieving humans of attending to complex procedures not directly related to their 
primary objectives. , 

—providing knowledgeable assistance in executing higher level decision making 
functions. 

—increasing the rate of decision making beyond that reasonably supportable by a 
human controller. 

At the intersection of computers, control, information, and management, design for high 
autonomy requires the tools of Al and Simulation to successfully integrate decision 
making and physical layers. Typical issues raised include design stage testability, multi¬ 
abstraction model/knowledge bases, discrete/continuous and symbolic/numeric 
interfaces, self-embedded model construction, and self-planning under behavior 
constraints. 

The conference will feature invited and contributed papers in the technical at™... 
simulation-evaluated planning and scheduling, qualitative reasoning, device modelling 
for operations/diagnostics/repair, knowledge-based simulation and design, multi-agent 
computer architectures and parallel simulators, discrete event dynamic systems, quality 
assurance issues, intelligent control, model-based perception, model reuse and evolution, 
embedded learning and adaptation, and related topics. 

Papers describing applications are also solicited in such areas as autonomous vehicles, 
telerobotics, factories of the future, design support environments, mission planmng 
support, logistics, wargaming, and in particular, novel applications which fuse modelling 
paradigms, e.g. combined cognitive/social/natural models and combined neural/ 
symbolic processing. 

Persons wishing to present papers should submit four copies of an abstract. Abstracts 
should be not more than three double-spaced pages, including fjguresand representative 


citations. Abstracts must be received not later than Friday, November 17, ..._ 

abstracts to The Office of Engineering Professional Development Universitv of Arizona 
Box 9 Harvill Building, Tucson, AZ 85721, (602) 621-3054 or FAX: 602) 621-1443. Accepted 
papers will be determined by December 15,1989. Proceedings will be published in a form 
permitting wide distribution. Selected papers may be published in a special issue of a 
major journal. 
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CALL FOR PAPERS 


IEEE Micro seeks articles for general¬ 
ly interest issues in 1990. Suggested topics 
include neural networks, artificial intelli¬ 
gence, special-purpose computers, optical 
computers and interfaces, workstations, use of 
microprocessors in parallel computers, VHDL 
design, silicon compilation, and biological 
computing. Tutorials are welcome on all micro- 
related topics. Submit manuscripts to Joe 
Hootman, Editor-in-Chief, EE Dept., Univ. of 
North Dakota, PO Box 7165, Grand Forks, ND 
58202, phone (701) 777-4331. 

NECC 90, 11th Nat’l Educational Comput¬ 
ing Conf.: June 25-27, 1990, Nashville, Tenn. 
Sponsor: Int’l Council for Computers in Edu¬ 
cation. Submit paper by Oct. 15, 1989, to John 
D. McGregor, Computer Studies Dept., Mur¬ 
ray State Univ., Murray, KY 42071, phone 
(502) 762-2614. 

.gN. Second Int’l Symp. on Databases in 
VS? Parallel and Distributed Systems: July 
2-4, 1990, Dublin, Ireland. Cosponsor: ACM. 
Submit paper by Oct. 16, 1989, to Rakesh 
Agrawal, AT&T Bell Labs, Rm. 3D450, 600 
Mountain Ave., Murray Hill, NJ 07974, phone 
(201) 582-2250; or David Bell, Inst, of Infor¬ 
matics, Univ. of Ulster, Jordanstown, County 
Antrim, Northern Ireland BT370QB, phone 
(0232) 365-131. 

ICDCS 10,10th Int’l Conf. on Distrib- 

uted Computing Systems: May 28-June 
1, 1990, Paris. Cosponsor: INRIA. Submit ab¬ 
stract and paper by Oct. 20, 1989, to Jack 
Stankovic, Computer and Information Science 
Dept., Univ. of Massachusetts, Amherst, MA 
01003, phone (413) 545-0720; or R. Popescu- 
Zeletin, GMD-FOCUS, Hardenbergplatz 2, D- 
1000 Berlin 12, West Germany, phone 49 (30) 
25499-206. 

Parbase 90, Int’l Conf. on Databases, Paral¬ 
lel Architectures, and Their Applications: 

Mar. 6-9, 1990, Miami Beach. Sponsor: Flor¬ 
ida Int’l Univ. Submit abstract by Oct. 27, 

1989, to Parbase 90, School of Computer Sci¬ 
ence, Florida Int’l Univ., Miami, FL 33199, 
phone (305) 554-3386. 

Fourth Int’l Symp. on Knowledge Engineer¬ 
ing: May 7-11, 1990, Barcelona, Spain. Spon¬ 
sor: Madrid Polytechnic Univ. Submit paper 
by Oct. 30, 1989, to Juan Castellanos, ISKE, 
Facultad de Informatica, Universidad Po- 
litecnica de Madrid, Campus de Mon- 
tegancedo s/n, Boadilla del Monte, 28660 
Madrid, Spain. 

ICCI 90, Int’l Conf. on Computing and In¬ 
formation: May 23-26, 1990, Niagara Falls, 
Canada. Sponsor: Natural Sciences and Engi¬ 


neering Research Council of Canada. Submit 
paper by Oct. 31,1989, to Waldemar W. 
Koczkodaj, ICCI 90, Laurentian Univ., CoSc, 
Sudbury, Ont., Canada P3E 2C6. 

/gi\ 20th Int’l Symp. on Multiple-Valued 
^*7 Logic: May 23-25, 1990, Charlotte, N.C. 
Cosponsors: Microelectronic Center of North 
Carolina, Univ. of North Carolina. Submit pa¬ 
per by Nov. 1,1989, to George Epstein, Com¬ 
puter Science Dept., Univ. of North Carolina at 
Charlotte, Charlotte, NC 28223, phone (704) 
547-4566. 

IEEE Trans, on Computers plans a spe- 
'^57 cial issue on computer arithmetic in Au¬ 
gust 1990. Submit paper by Nov. 1, 1989, to 
Earl Swartzlander, TRW Defense Systems 
Group, 1 Space Park, Redondo Beach, CA 
90278, phone (213) 812-0791. 

IEEE Trans, on Reliability plans a spe- 
^57 cial issue on experimental evaluation of 
computer systems reliability. Submit abstract 
by Nov. 1,1989, and paper by Jan. 15,1990, to 
Ram Chillarege, T.J. Watson Research Center, 
PO Box 704, Yorktown Heights, NY 10598, 
phone (914) 789-7375; or Daniel P. Siewiorek, 
School of Computer Science, Carnegie Mellon 
Univ., Pittsburgh, PA 15213-3890, phone 
(412) 268-2570. 

J. Parallel and Distributed Computing plans a 
special issue on software tools for parallel pro¬ 
gramming and visualization in June 1990. Sub¬ 
mit paper by Nov. 1,1989, to Lionel Ni, Com¬ 
puter Science Dept., Michigan State Univ., 

East Lansing, MI 48824-1027, phone (517) 
353-4386; or K.C. Tai, Computer Science 
Dept., North Carolina State Univ., Raleigh, NC 
27695-8206, phone (919) 737-7862. 

Seventh Int’l Conf. on Testing Computer 
Software: June 18-21, 1990, San Francisco. 
Submit abstract by Nov. 1, 1989, to Genevieve 
Houston-Ludlam, ISTC 90, c/o Frontier Tech¬ 
nologies, 190 Admiral Cochran Dr., Suite 180, 
Annapolis, MD 21401, phone (301) 266-8244. 

COIS 90, Conf. on Office Information 

Systems: Apr. 25-27, 1990, Cambridge, 
Mass. Cosponsor: ACM. Submit paper by Nov. 

3, 1989, to Fred Lochovsky, Computer Science 
Dept., 10 King’s College Circle, Univ. of 
Toronto, Toronto, Ont. M5S 1A4, Canada, 
phone (416) 978-7441. 

/git DAC 90, 27th ACM/IEEE Design 

Automation Conf.: June 25-29, 1990, 
Orlando, Fla. Submit paper by Nov. 6,1989 to 
MP Associates, Atm. Alfred E. Dunlop, 7490 
Clubhouse Rd„ Suite 102, Boulder, CO 80301 
phone (303) 530-4333. 


( g^ | 1990 IEEE Symp. on Research in Secu- 
sg? 1 rity and Privacy: May 7-9, 1990, 
Oakland, Calif. Cosponsor: Int’l Assoc, for 
Cryptologic Research. Submit paper by Nov. 

6, 1989, to Deborah Cooper, Unisys Corp., 

5731 Slauson Ave., Culver City, CA 90230, 
phone (213) 338-3727. 


CGI 90, Computer Graphics Int’l 1990: June 
26-30, 1990, Kent Ridge, Singapore. Spon¬ 
sors: Computer Graphics Society, Inst, of Sys¬ 
tems Science, Singapore. Submit paper by 
Nov. 10,1989, to T.S. Chua, CGI 90, ISS, Nat’l 
Univ. of Singapore, Kent Ridge, Singapore 
0511, phone (65) 772-3110. 

ICALP 90, 17th Int’l Colloquium on Auto¬ 
mata, Languages, and Programming: July 
16-20, 1990, Coventry, England. Sponsor: 

Int’l Computers, Ltd. Submit extended ab¬ 
stract or draft by Nov. 15,1989, to Mike S. Pa¬ 
terson, Computer Science Dept., Univ. of War¬ 
wick, Coventry CV4 7AL, UK, phone 44 (203) 
523-194. 

1990 Summer Computer Simulation Conf.: 

July 16-18, 1990, Calgary, Alta., Canada. 
Sponsor: Society for Computer Simulation. 
Submit paper by Nov. 15,1989, to William Y. 
Svrcek, Chemical and Petroleum Engineering 
Dept., Univ. of Calgary, 2500 University Ave. 
NW, Calgary, Alta., Canada T2N 1N4, phone 
(403) 220-5755. 

Int’l J. of Computer-Aided VLSI Design plans 
a special issue on VLSI layout algorithms. Sub¬ 
mit paper by Nov. 15, 1989, to Majid Sarraf- 
zadeh, EE-CS Dept., Technological Inst., 
Northwestern Univ., Evanston, IL 60208, 
phone (312) 491-7378. 

Third Int’l Symp. on Image Conservation: 

June 17-20, 1990, Rochester, N.Y. Sponsor: 
Society for Imaging Science and Technology. 
Submit abstract by Nov. 15, 1989, to William 
E. Lee, 3 Woodland Circle, Rochester, NY 
14622; or N.S. Allen, Chemistry Dept., Fac¬ 
ulty of Science and Engineering, Manchester 
Polytechnic, Chester St., Manchester, Ml 
5GD, UK. 

1990 European Simulation Multiconfer¬ 
ence: June 10-13, 1990, Erlangen, Federal Re¬ 
public of Germany. Sponsor: SCS Int’l. Submit 
extended abstract by Nov. 15, 1989, to Win- 
fried Hahn, Univ. of Passau, Computer Science 
Dept., D-8390, Passau, FRG, phone (49) 851- 
509-320. 

1990 AAAI Spring Symp. on the Theory and 
Application of Minimal-Length Encoding: 

Mar. 27-29, 1990, Stanford, Calif. Submit pa¬ 
per by Nov. 17,1989, to Edwin Pednault, 
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Call for papers and referees for Computer 


Computer seeks articles for inclusion in upcoming 
special issues. 

Fault-Tolerant Systems has been selected as the theme 
for the July 1990 edition. Submittals should be either tutorial 
or survey in nature, describe state-of-the-art designs, or re¬ 
port recent developments and research findings in the follow¬ 
ing areas: fault-tolerant hardware, fault-tolerant software, 
fault-tolerant distributed systems and networks, modeling and 
evaluation, fault-tolerant commercial systems, special-pur¬ 
pose designs, and emerging areas. 

Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract of the manuscript is due as soon as pos¬ 
sible, and eight copies of the full manuscript must be submitted 
by November 1, 1989, to Adit D. Singh, Electrical and Com¬ 
puter Engineering, University of Massachusetts, Amherst, MA 
01003, phone (413) 545-0188, electronic-mail: 
singh@umaecs.edu; or Singaravel Murugesan, Information 
Sciences Division, NASA Ames Research Center, MS 244-4, 
Moffett Field, CA 94035, phone (415) 694-4233, ARPAnet 
murugesan@pluto.arc.nasa.gov 

Authors will be notified of acceptance by February 1,1990. 
The final version of the manuscript is due no later than March 
1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 
Bruce Shriver, Editor-in-Chief, Computer, c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Compmail+ 
b.shriver, Internet shriver@usl.edu 

Voice In Computing has been selected as the theme for the 
August 1990 edition. Surveys, tutorials, system or application 
descriptions, or case studies are solicited in the following ar¬ 
eas: computer interface to voice communications, voice ma¬ 
nipulation by computer, computer voice applications, inte¬ 
grated voice/data applications, voice in computer user inter¬ 
faces, speech synthesis or recognition systems, and com¬ 
puter architectures for supporting voice. 

Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract of the manuscript is due as soon as pos¬ 
sible, and eight copies of the full manuscript must be submitted 
by November 1, 1989, to Ragui Kamel, Computing Research 
Laboratory, Bell-Northern Research, PO Box 3511 — Station 
C, Ottawa, Canada K1Y 4H7, phone (613) 763-3609, fax (613) 
763-4222, electronic mail Ragui@BNR.CA 

Authors will be notified of acceptance by January 1,1990. 


The final version of the manuscript is due no later than March 
1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 
Bruce Shriver, Editor-in-Chief, Computer, c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Compmail+ 
b.shriver, Internet shriver@usl.edu 

Cache and Interconnect Architectures in Multiproces¬ 
sors has been selected as the theme for the June 1990 edition. 
Manuscripts are sought immediately in the following areas: 

• New solutions to the cache coherence problem: novel 
hardware protocols and compiler-assisted cache proto¬ 
cols; emphasis is on protocols for nonbus systems. 

• Detailed descriptions of existing commercial systems and 
university or industry prototypes. 

• Caching support for virtual memory and virtual-address 
caches in multiprocessors. 

• Trace-driven simulation techniques and results for cache- 
based multiprocessors. 

• Other performance-evaluation techniques, such as mea¬ 
surements, execution-driven simulation, and analytical 
models. 

In addition, a tutorial paper on cache coherence and virtual 
memory for multiprocessor systems is solicited. This tutorial 
should contain background material needed by a computer 
scientist unfamiliar with the theme of this special issue. 

Articles must not have been previously published or cur¬ 
rently submitted for publication elsewhere. 

A 300-word abstract should be submitted by e-mail or fax as 
soon as possible. Eight copies of the full manuscript must be 
submitted by November 1, 1989, to Michel Dubois, Depart¬ 
ment of EE-Systems, Univ. of Southern California, Los Ange¬ 
les, CA 90089-0781, phone (213) 743-8080, fax (213) 745- 
7284, electronic-mail dubois@cse.usc.edu; or Shreekant 
Thakkar, Sequent Computer Systems, 15450 SW Koll Park¬ 
way, Beaverton, OR 97006, phone (503) 627-9822, fax (503) 
526-5797, electronic-mail sequentlticky@decwrl.dec.com 

Authors will be notified of acceptance by January 1, 1990. 
The final version of the manuscript is due no later than March 
1, 1990. 

Persons interested in serving as referees are asked to send 
a note indicating their technical interests and qualifications to 
Bruce Shriver, Editor-in-Chief, Computer, c/o the University of 
Southwestern Louisiana, Drawer 42730, Lafayette, LA 70504- 
2730, phone (318) 231-5811, fax (318) 265-5472, Compmaik 
b.shriver, Internet shriver@usl.edu 


AT&T Bell Laboratories, Rm. 4F-611, 
Crawfords Comer Rd., Holmdel, NJ 07733, 
phone (201) 949-1074. 

1990 AAAI Spring Symp. on Knowledge- 
Based Environments for Learning and 
Teaching: Stanford, Calif. Submit paper by 
Nov. 17, 1989, to Beverly P. Woolf, Computer 
and Information Science, Univ. of Massachu¬ 
setts, Amherst, MA 01003, phone (413) 549- 
0065. 


17th Int’l Symp. on Computer Archi- 
'SU' tecture: May 28-31, 1990, Seattle. Co¬ 
sponsor: ACM. Submit paper by Nov. 21, 
1989, to James Goodman, Computer Sciences 
Dept., Univ. of Wisconsin, 1210 W. Dayton, 
Madison, WI 53706, phone (608) 262-1204. 


Flairs 90, Florida AI Research Symp.: Apr. 
3-6, 1990, Cocoa Beach, Fla. Submit abstract 
by Nov. 27,1989, to Douglas D. Dankel II, 
Hairs 90, E301 CSE, C.I.S., Univ. of Florida, 
Gainesville, FL 32611, phone (904) 335-8034. 


First Int’l Symp. on Environments and 
Tools for Ada: Apr. 30-May 2, 1990, 
Redondo Beach, Calif. Cosponsor: ACM. Sub¬ 
mit paper by Dec. 4,1989, to Dewayne E. Perry, 
AT&T Bell Laboratories, 600 Mountain Ave., 
Murray Hill, NJ 07974, phone (201) 582-2529. 


En 1990 IEEE VLSI Test Workshop: Apr. 
Vj) 10-11, 1990, Atlantic City, NJ. Cospon- 
r: IEEE Philadelphia Section. Submit ab- 
act by Dec. 15,1989, to Mukund Modi, Na¬ 


val Air Engineering Center, ATE Software 
Center, Code: 52514, Lakehurst, NJ 08733. 


Fourth Parallel Processing and Neu- 
'^§7 ral Network Symp.: Apr. 3-5, 1990, 
Fullerton, Calif. Cosponsor: California State 
Univ. at Fullerton. Submit paper by Dec. 15, 

1989, to Larry H. Canter, c/o Computer Sys¬ 
tems Approach, 1140 S. Raymond Ave., Suite 
B„ Fullerton, CA 92631. 

Second IEEE Symp. on Parallel and 
Distributed Processing: Dec. 10-12, 

1990, Dallas. Sponsor: Dallas Section of the 
IEEE Computer Society. Submit paper by May 
1, 1990, to Behrooz Stiirazi, Computer Science 
and Engineering Dept., Southern Methodist 
Univ., Dallas, TX 75275, phone (214) 692-2874. 
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CALL FOR PAPERS 
— 19th Annual Conference — 


1990 International Conference on 
Parallel Processing 

August 13-17, 1990 
The Pennsylvania State University 



Authors are invited to submit papers describing recent 
advances on all aspects of parallel/distributed processing. 
These may include parallel/distributed logic circuits, impact 
of VLSI to parallel processor architecture; various 
concurrent-, parallel-, pipeline-, or multiple-processor 
architectures; processor-memory interconnections; 
computer networks; distributed databases; reliability and 
fault tolerance; modeling and simulation techniques; 
performance measurements; operating systems; languages; 
compilers; algorithms; or various application studies. 

INSTRUCTIONS FOR AUTHORS 

The deadline for submitting papers is January 10,1990. 

Submit five (5) copies each of a 100-word abstract and the 
full text (including five specific key words) to one of the 
following Technical Program Co-Chairpersons according to 
their areas of responsibility; 

ALGORITHMS AND APPLICATIONS papers to: 

Pen-Chung Yew (217) 244-0045 (Off.) 

Center for Supercomputing yew@uicsrd.csrd.uiuc.edu 

Research and 
Development (CSRD) 

305 Talbot Laboratory 
104 South Wright Street 
University of Illinois 
Urbana, IL 61801-2932 

SOFTWARE-ORIENTED papers to: 

David A. Padua (217) 333-4223 (Off.) 

Center for Supercomputing padua@a.cs.uiuc.edu 

Research and 
Development (CSRD) 

305 Talbot Laboratory 
104 South Wright Street 
University of Illinois 
Urbana, IL 61801-2932 

HARDWARE-ORIENTED AND OTHER papers to: 

Benjamin W. Wah (217) 333-3516 (Off.) 

Coordinated Science (217) 244-7175 (Sec.) 

Laboratory (217) 244-1764 (Fax) 

University of Illinois wah%aquinas@uxc.cso.uiuc.edu 
1101 West Springfield Avenue 
Urbana, IL 61801-3082 

Please limit the length of your paper to about 20 double¬ 
spaced typing pages, and include your office and/or home 
phone numbers as well as your electronic mail address (if 
available). Submitted papers will be acknowledged 
promptly. 

Selected papers are published as either regular or short 
papers. Authors will be notified of acceptance by March 20, 

1990. Due to the large number of papers we receive every 
year, authors are expected to help in reviewing papers for 
the conference. 


Please note the deadline for submitting papers is January 
10,1990. 

CONFERENCE PROCEEDINGS 

The regular papers and the summaries of the short papers 
will be published in the conference proceedings. Special 
sheets for the preparation of accepted papers for the 
proceedings will be sent to each author. 

CONFERENCE AWARDS 

The conference will give two awards: one for the Daniel L. 
Slotnick Award for Most Original Paper, and the other for 
Best Presentation. In addition, a small number of awards 
may be given for Outstanding Papers and Distinguished 
Presentations. 

CONFERENCE ENVIRONMENT 

The Conference is tentatively scheduled at the Pheasant 
Run Resort in St. Charles, Illinois. Pheasant Run is only 45 
minutes from Chicago’s loop and 25 miles from O’Hare 
International Airport. 

The Resort is located in DuPage County, Illinois, and is 
situated on 300 acres in the bautiful Fox River Valley near 
St. Charles, Illinois. The 500 newly renovated rooms are 
homey and gracious with scenic views of a small lake or a 
beautiful golf course. On a clear day the Chicago skyline is 
visible from the upper levels of its sleek 15 story Tower. 
Special entertainment is available nightly. 

There is transportation available through the Hotel Trans¬ 
portation Department between Pheasant Run and O’Hare 
International Airport (or Midway Airport). 

Informal, open bar gatherings will be held nightly for the 
conference participants. 

A conference brochure with pre-registration form and 
advance technical program will be prepared and mailed in 
May/June 1990. 

TUTORIALS 

Pre-conference (on August 13) and post-conference (on 
August 17) tutorials relating to parallel processors and 
processing will be offered. 

EXHIBITS 

An exhibition of newly developed equipment (and software) 
by vendors is planned. For further information and possible 
participation by your company, please contact: 


Roger E. Anderson (415) 422-8572 

P.O. Box 808, L-306 

Lawrence Livermore National Lab 

Livermore, CA 94550 









CALENDAR 


✓gs The accompanying Calendar section is now printed with a colored back- 
ground to make it easier to find. The IEEE Computer Society logo indicates 
the conferences the society is sponsoring and participating in; additional confer¬ 
ence sponsors are also listed. Other conferences of interest to our readers are in¬ 
cluded, as well. 

For inclusion in Call for Papers or Calendar, submit information six weeks be¬ 
fore the month of publication (i.e., for the December 1989 issue, send informa¬ 
tion for receipt by October 15,1989) to Chuck Governale, Calendar Dept., Com¬ 
puter, PO Box 3014, Los Alamitos, CA 90720. 


October 1989 


Fourth Int’l High-Level Synthesis 
Workshop, Oct. 15-19, Kennebunk- 
port, Maine. Cosponsor: ACM. Contact Gae¬ 
tano Borriello, Computer Science Dept., FR 
35, Univ. of Washington, Seattle, WA 98195, 
phone (206) 543-1695. 

Data and Knowledge Systems for 
'sU' Manufacturing and Engineering, Oct. 
16-18, Gaithersburg, Md. Cosponsor: ACM. 
Contact Lawrence A. Rowe, Computer Sci¬ 
ence Div. — EECS, Univ. of California, 
Berkeley, CA 94720, phone (415) 642-5117. 

CSM 89, Conf. on Software Mainte- 
nance, Oct. 16-19, Miami, Fla. Contact 
CSM 89, IEEE Computer Society, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013; or Wilma 
Osborne, NIST, Bldg. 225, Rm. B266, Gaith¬ 
ersburg, MD 20899, phone (301) 975-3339. 


cal Engineering Dept., Univ. of South Florida, 
Tampa, FL 33620, or Charles H. Stapper, Dept. 
A23, Bldg. 861-1, IBM, Essex Junction, VT 
05452, phone (802) 769-6655. 


IEEE Computer Society Workshop on 
Tools for Artificial Intelligence, Oct. 
23-25, Fairfax, Va. Contact Nikolas G. Bour- 
bakis. Machine Vision Research Lab, ECE 
Dept., SITE, George Mason Univ., 4400 Uni¬ 
versity Dr., Fairfax, VA 22030, phone (703) 
425-3930. 


1989 Beijing Int’l Conf. on System Simula¬ 
tion and Scientific Computing, Oct. 23-26, 

Beijing, China. Sponsors: Society for Com¬ 
puter Simulation et al. Contact Wen Chuan- 
Yuan, Beijing Inst, of Aeronautics and Astro¬ 
nautics, Beijing, China. 

Second Int’l Symp. on Artificial Intelligence, 
Oct. 23-27, Monterrey, Mexico. Contact Fran¬ 
cisco J. Cantu, Inst. Tecnologico de Monter¬ 
rey, ITESM Sue. Correos “J," Monterrey, 

N.L., Mexico 64849, phone 52 (83) 58-20-00. 


First Int'l Conf. on Artificial Neural Net¬ 
works, Oct. 17-18, London. Sponsor: Institu¬ 
tion of Electrical Engineers. Contact Conf. 
Services, IEE, Savoy PL, London WC2R 0BL, 
UK, phone 44 (1) 24-01-871. 

Eighth Int’l Conf. on Entity-Relationship 
Approach, Oct. 18-20, Toronto. Sponsor: ER 
Inst. Contact Frederick H. Lochovsky, Com¬ 
puter Science Dept., Univ. of Toronto, Stan¬ 
ford Fleming Bldg., 10 King’s College Circle, 
Toronto, Ont. M5S 1A4, Canada, phone (416) 
978-7441. 


Workshop on Large-Scale Numerical Opti¬ 
mization, Oct. 19-20, Ithaca, N Y. Sponsor: 
Mathematical Sciences Inst. Contact MSI, 201 
Caldwell Hall, Cornell Univ., Ithaca, NY 
14853-2602, phone (607) 255-7740. 


Int’l Workshop on Defect and Fault 
Tolerance in VLSI Systems, Oct. 23- 
25, Tampa, Fla. Contact D.L. Landis, Electri¬ 


IEEE Computer Society Workstation 
'^57 Symp.: Design, Office, Personal, Oct. 
24-26, Laurel, Md. Contact Paul L. Hazan, 
JHU/Applied Physics Laboratory, John 
Hopkins Rd., Laurel, MD 20707, phone (301) 
953-5364. 

23rd Asilomar Conf. on Signals, Sys- 
terns, and Computers, Oct. 30-Nov. 1, 

Pacific Grove, Calif. Cosponsors: Naval Post¬ 
graduate School, San Jose State Univ. Contact 
John T. Rickard, Orincon Corp., 9363 Towne 
Centre Dr., San Diego, CA 92121, phone (619) 
455-5530. 

Third IFAC Workshop on Experience 
with the Management of Software 
Projects, Oct. 30-Nov. 1, West Lafayette, Ind. 
Sponsor: Purdue Univ. Contact Frederic J. 
Mowle, School of Electrical Engineering, Pur¬ 
due Univ., West Lafayette, IN 47907, phone 
(317) 494-3440. 


FOCS 89, 30th Foundations of Com- 
'Qy puter Science Conf., Oct. 30-Nov. 1, 
Research Park, N.C. Contact Christos Papa- 
dimitriou. Computer Science Dept., Univ. of 
California at San Diego, La Jolla, CA 92093, 
phone (619) 534-2086. 


ISCIS 4, Fourth Int’l Symp. on Computer 
and Information Sciences, Oct. 30-Nov. 1, 
Cesme, Turkey. Contact Asuman Dogac, Com¬ 
puter Engineering Dept., Middle East Techni¬ 
cal Univ., 06531 Ankara, Turkey. 


CIPS Edmonton 89, Oct. 30-Nov. 1, Edmon¬ 
ton, Alta., Canada. Sponsor: Canadian Infor¬ 
mation Processing Society. Contact Wayne A. 
Davis, Computing Science Dept., Univ. of Al¬ 
berta, Edmonton, Alta., Canada T6G 2H1, 
phone (403) 492-3976. 

FedCASE 89, Federal CASE Conf., 

Oct. 30-Nov. 2, Gaithersburg, Md. 
Sponsor: Nat’l Inst, of Standards and Technol¬ 
ogy. Contact Margaret H. Law or Wilma M. 
Osborne, NIST, Technology Bldg., Gaithers¬ 
burg, MD 20899, or 2107 Vermont Ave., Lan- 
dover, MD 20785. 


November 1989 


Ninth Symp. on Small Computers in 
the Arts, Nov. 3-5, Philadelphia, Pa. 
Sponsor: Small Computers in the Arts Network. 
Contact Dick Moberg, PO Box 1954, Philadel¬ 
phia, PA 19105, phone (215) 923-3299. 

Fifth Knowledge Acquisition for Knowl¬ 
edge-Based Systems Workshop, Nov. 4-9, 
Banff, Canada. Sponsor: American Assoc, for 
Artificial Intelligence. Contact John H. Boose, 
Advanced Technology Center, Boeing Com¬ 
puter Services, 7L-64, PO Box 24346, Seattle, 
WA 98124, phone (206) 865-3253. 

13th Symp. on Computer Applications in 
Medical Care, Nov. 5-8, Washington, DC. 
Contact Office of Continuing Medical Educa¬ 
tion, George Washington Univ. Medical Cen¬ 
ter, 2300 K. St. NW, Washington, DC 20037, 
phone (202) 994-8928. 

Advances in Intelligent Robotic Systems, 
Nov. 5-10, Philadelphia. Sponsor: SPIE. Con¬ 
tact Int’l Society for Optical Engineering, PO 
Box 10, Bellingham, WA 98227-0010, phone 
(206) 676-3290. 


ICCAD 89, IEEE Int’l Conf. on Com- 
puter-Aided Design, Nov. 6-9, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Society. Contact Andrezej J. 
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Strojwas, ECE Dept., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 268- 
3530; or IEEE Computer Society, 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

GOMAC 89, Government Microcircuit Ap¬ 
plications Conf., Nov. 7-9, Orlando, Fla. 
Sponsors: US Dept, of Energy et al. Contact 
Randolph A. Reitmeyer, Electronics Technol¬ 
ogy and Devices Lab., Attn.: SLCET-I, Ft. 
Monmouth, NJ 07703-5000, phone (201) 544- 
3465. 


sponsors: George Mason Univ., Inst, for De¬ 
fense Analyses, Software Productivity Con¬ 
sortium. Contact AIDA 89, Computer Science 
Dept., George Mason Univ., 4400 University 
Dr., Fairfax, VA 22030, phone (703) 323- 
2713. 

Tencon 89, IEEE Region 10 Conf., Nov. 22- 
24, Bombay, India. Sponsor: IEEE Bombay 
Section. Contact Kirit J. Sheth, Hakotronics 
Pvt. Ltd., Victoria Gardens, 20 Sussex Rd., 
Bombay 400 027, India, phone 91 (22) 872- 
2888. 


Cosponsors: ACM, Univ. of British Columbia. 
Contact Son T. Vuong, Univ. of British Colum¬ 
bia, 6356 Agricultural Rd., Vancouver, B.C., 
Canada, phone (604) 228-6366. 

Third Int’l Workshop on Petri Nets 
and Performance Models, Dec. 11-13, 

Kyoto, Japan. Cosponsors: Society of Instru¬ 
ment and Control Engineers et al. Contact 
Shojiro Nishio, Information and Computer 
Science Dept., Faculty of Engineering Sci¬ 
ences, Osaka Univ., Toyonaka, Osaka, 560 Ja¬ 
pan, phone 81 (6) 853-5737. 


Fifth Int’l Congress on Advances in Non¬ 
impact Printing Technologies, Nov. 12-17, 
San Diego, Calif. Sponsor: Society for Imag¬ 
ing Science and Technology. Contact Wayne 
Jaeger, Tektronix, PO Box 500, MS 50-321, 
Beaverton, OR 97077, phone (503) 627-6714. 

Prociem 89, Second Conf. on Productivity 
through Computer Integrated Engineering 
and Manufacturing, Nov. 13-15, Orlando, 
Fla. Sponsor: Florida High Technology and 
Industry Council. Contact Vince Amico, Univ. 
of Central Florida, College of Extended Stud¬ 
ies, PO Box 25000, Orlando, FL 32816, phone 
(407) 275-2123. 

UIST 89, Second Symp. on User Interface 
Software and Technology, Nov. 13-15, Wil¬ 
liamsburg, Va. Sponsor: ACM. Contact John 
Sibert, UIST 89, EE and CS Dept., George 
Washington Univ., 801 22nd St. NW, Wash¬ 
ington, DC 20052. 


IEEE Workshop on Interpretation of 
3D Scenes, Nov. 27-29, Austin, Texas. 
Contact Anil K. Jain, Computer Science Dept., 
Michigan State Univ., A-714 Wells Hall, East 
Lansing, MI 48824, phone (517) 353-5150. 


December 1989 


WSC 89, Winter Simulation Conf., 
Dec. 3-6, Washington, DC. Cosponsors: 
Society for Computer Simulation et al. Contact 
Sallie Sheppard, Office of Associate Provost, 
103 Academic Bldg., Texas A&M Univ., Col¬ 
lege Station, TX 77843, phone (409) 845- 
3210; or Philip Heidelberger, IBM Research 
Div., T.J. Watson Research Center, Haw¬ 
thorne, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 789-7156. 


Fourth SIAM Conf. on Parallel Processing 
for Scientific Computing, Dec. 11-13, Chi¬ 
cago. Sponsor: Society for Industrial and Ap¬ 
plied Mathematics. Contact SIAM Conf. Coor¬ 
dinator, 117 S. 17th St., 14th Floor, Philadel¬ 
phia, PA 19103-5052, phone (215) 564-2929. 

KBCS 89, Conf. on Knowledge-Based Com¬ 
puter Systems: Dec. 11-13, Bombay. Spon¬ 
sor: Government of India Dept, of Electronics. 
Contact S. Ramani, KBCS 89, National Centre 
for Software Technology, Gulmohar Cross Rd. 
No. 9, Juhu, Bombay 400 049, India. 

Int’l Conf. on CAD/CAM and Ad- 

vanced Manufacturing Technology in 
Israel, Dec. 19-21, Jerusalem, Israel. Cospon¬ 
sors: Israel Society for CAD/CAM, SME. Con¬ 
tact Lawrence R. Odess, Ortra, PO Box 50432, 
61500 Tel Aviv, Israel, phone 972 (3) 971- 
3991 or 664-825. 


IFIP Int’l Workshop on Applied Formal 
Methods for Correct VLSI Design, Nov. 13- 
16, Leuven, Belgium. Cosponsors: IFIP, In¬ 
teruniversity Micro Electronics Center. Con¬ 
tact Luc Claesen, IMEC vzw, Kapeldreef 75, 
B-3030 Leuven, Belgium phone 32 (16) 281- 
203. 


Supercomputing 89, Nov. 13-17, Reno, 
Nev. Cosponsor: ACM. Contact F. Ron 
Bailey, MS 258-5, NASA Ames Research Cen¬ 
ter, Moffett Field, CA 94035, phone (415) 694- 
4500. 


First Int’l Conf. on Deductive and 
Object-Oriented Databases, Dec. 4-6, 
Kyoto, Japan. Sponsor: Information Pro¬ 
cessing Society of Japan. Contact Won Kim, 
MCC, 3500 W. Balcones Center Dr., Austin, 
TX 78759, phone (512) 338-3439; Jean-Marie 
Nicholas, ECRC Arabellastr. 17, 8000 Munich 
81, FRG, phone 49 (89) 926-99-110; or Shojiro 
Nishio, Information and Computer Science 
Dept., Faculty of Engineering Sciences, Osaka 
Univ., Toyonaka, Osaka, 560 Japan, phone 81 
(6) 853-5737. 


Ninth Conf. on Foundations of Software 
Technology and Theoretical Computer Sci¬ 
ence, Dec. 19-21, Bangalore, India. Contact 
C.E. Veni Madhavan, Tata Research Develop¬ 
ment and Design Center, 1 Mangaldas Rd., 
Pune 411001, India, phone (212) 662-453. 

Sixth Israeli Conf. on Artificial Intelligence 
and Computer Vision, Dec. 26-27, Tel Aviv. 
Sponsor: Information Processing Assoc, of Is¬ 
rael. Contact IPA, PO Box 13009, 91130 
Jerusalem, Israel. 


Semiconductor Manufacturing Conf., Nov. 
14-15, Phoenix. Sponsor: Society of Manufac¬ 
turing Engineers. Contact Karen L. Kammerer, 
Technical Committee Projects Dept., SME, 1 
SME Dr., PO Box 930, Dearborn, MI 48121, 
phone (313) 271-1500. 

Wescon 89, Nov. 14-16, San Francisco. Co¬ 
sponsors: IEEE Los Angeles Council and San 
Francisco Bay Area Council, ERA. Contact 
Wescon 89, 8110 Airport Blvd., Los Angeles, 
CA 90045, phone (213) 772-2965. 

Western Educational Computing Conf., 

Nov. 16-17, Burlingame, Calif. Sponsor: Cali¬ 
fornia Educational Computing Consortium. 
Contact Judah Rosenwald, Extended Educa¬ 
tion, NAD 153, San Francisco State Univ., 

1600 Holloway, San Francisco, CA 94132, 
phone (415) 338-1212. 

AIDA 89, Fifth Conf. on Artificial Intelli¬ 
gence and Ada, Nov. 16-17, Fairfax, Va. Co¬ 


Fifth Computer Security Applications 
Conf., Dec. 4-8, Tucson, Ariz. Sponsors: 
American Society for Information Science, 
ACSA. Contact Diana Akers or Victoria 
Ashby, Mitre Corp., 7525 Colshire Dr., 
McLean, VA 22102, phone (703) 883-5907 
(for Akers) and (703) 883-6368 (for Ashby). 

10th Real-Time Systems Symp., Dec. 
'^57 5-7, Santa Monica, Calif. Contact Al 
Mok, Computer Science Dept., TAY 3-140C, 
Univ. of Texas, Austin, TX 78712, phone (512) 
471-9542. 


SIGSoft 89, Third Testing, Analysis, 
and Verification Symp., Dec. 6-8, Key 

West, Fla. Cosponsor: ACM. Contact Richard 
A. DeMillo, Purdue Univ., Computer Science 
Dept., West Lafayette, IN 47907, phone (317) 
494-7823. 

Second Int’l Conf. on Formal Descrip- 
NS? tion Techniques/Distributed Systems, 
Dec. 6-9, Dec. 6-9, Vancouver, B.C., Canada. 


January 1990 


HICSS 23, 23rd Hawaii Int’l Conf. on 
System Sciences, Jan. 3-5, Kailua- 
Kona, Hawaii. Sponsor: Univ. of Hawaii. Con¬ 
tact Luqi, Computer Science Dept., Naval 
Postgraduate School, Monterey, CA 93943, 
phone (408) 646-2735. 


First Int’l Symp. on Artificial Intelligence 
and Mathematics, Jan. 3-5, Fort Lauderdale, 
Fla. Contact Frederick Hoffman, Mathematics 
Dept., Florida Atlantic Univ., PO Box 3091, 
Boca Raton, FL 33431-0991, phone (407) 367- 
3340. 


Winter 1990 Usenix Tech. Conf., Jan. 22-26, 

Washington, DC. Contact Daniel V. Klein, 
Software Engineering Inst., Carnegie Mellon 
Univ., Pittsburgh, PA 15213-3890, phone 
(412) 268-7791. 
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Second IEEE Int’IConf. on Wafer 
'50' Scale Integration, Jan. 23-25, San 

Francisco. Contact Joe Brewer, 351 White Ce¬ 
dar Ln., Sevema Park, MD 21146, phone (301) 
765-1247. 

Ninth Int’l Conf. on Computing Meth- 
'55^' ods In Applied Sciences and Engineer¬ 
ing, Jan. 29-Feb. 2, Paris. Cosponsor: INRIA. 
Contact INRIA, Service des Relations Exter- 
ieures, Domaine de Coloques — BP 105, 
78153, Rocquencourt, France; phone 33 (1) 
39-63-5600. 


February 1990 


First Workshop on Neural Networks: Aca- 
demic/Industrial/N AS A/Defense T echnical 
Interchange and Tutorials, Feb. 5-6, Au¬ 
burn, Ala. Sponsors: Space Power Inst. NASA/ 
Center for Commercial Development of Space 
Power and Auburn Univ. Contact Mary Lou 
Padgett, John Wu, or Ray Askew, EE Dept., 

200 Broun Hall, Auburn Univ., AL 36849, 
phone (205) 844-1855. 

£3^ Sixth Int’l Conf. on Data Engineering, 
'5*5' Feb. 5-9, Los Angeles. Contact Joseph E. 
Urban, Arizona State Univ., College of Engi¬ 
neering and Applied Sciences, Computer Sci¬ 
ence Dept., Tempe, AZ 85287, phone (602) 
965-2774; or Sixth Int’l Conf. of Data Engi¬ 
neering, IEEE Computer Society, 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

Applications Technology Conf., Feb. 12-15, 

San Jose, Calif. Sponsor: American Electron¬ 
ics Assoc. Contact Ed Teja, American Elec¬ 
tronics Assoc., 5201 Great American Pkwy., 
Santa Clara, CA 95054, phone (503) 231-9914. 

Eurasip Workshop on Neural Networks, 

Feb. 15-17, Sesimbra, Portugal. Cosponsors: 
European Assoc, for Signal Processing, IEEE, 
Instituto de Engenharia de Sistemas e Compu- 
tadores. Contact Luis B. Almeida, INESC, 
Apartado 10105, P-1017 Lisboa Codex, Portu¬ 
gal, phone 351 (1) 544-607. 

CSC 90, 18th Computer Science Conf., Feb. 
20-22, Washington, DC. Sponsor: ACM. Con¬ 
tact Barbara Kyriakakis, Computer Science 
Dept., George Mason Univ., Fairfax, VA 
22030, phone (703) 323-2318. 

IEEE Computer Society Compcon 
Spring 90, Feb. 26-Mar. 2, San Fran¬ 
cisco. Contact Kenichi Miura, Computational 
Research Dept., MS B2-7, Fujitsu America, 
3055 Orchard Dr., San Jose, CA 95134-2017, 
phone (408) 432-1300, ext. 5408 or 5723; or 
Compcon Spring 90, IEEE Computer Society, 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013. 

Third Int’l Software for Strategic Sys- 
terns Conf., Feb. 27-28, Huntsville, Ala. 
Cosponsors: IEEE Computer Society Hunts¬ 
ville Chapter et al. Contact Continuing Educa¬ 
tion Div., Univ. of Alabama in Huntsville, Tom 
Bevill Center 285, Huntsville, AL 35899, 
phone (800) 448-4035 or (205) 895-6372. 


March 1990 


Eighth Nat’l Conf. on Ada Technology, Mar. 
5-8, Atlanta. Contact Eighth Nat’l Conf. of 
Ada Technology, US Army Communications 
— Electronics Command, Attn.: AMSEL-RD- 
SE-CRM (Kay Trezza), Fort Monmouth, NY 
07703-5000. 

CAIA 90, Sixth IEEE Conf. on Artifi- 
'5*? cial Intelligence Applications, Mar. 5- 

9, Santa Barbara, Calif. Contact CAIA 90, 

IEEE Computer Society, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013; or Se June Hong, IBM 
T.J. Watson Research Center, Rm. 31-206, PO 
Box 218, Yorktown Heights, NY 10598, phone 
(914) 945-2265. 

Parbase 90, Int’l Conf. on Databases, Paral¬ 
lel Architectures, and Their Applications, 
Mar. 6-9, Miami Beach. Sponsor: Florida Int’l 
Univ. Contact Parbase 90, School of Computer 
Science, Florida Int’l Univ., Miami, FL 33199, 
phone (305) 554-3386 or 3429. 

EDAC 90, European Design Automa- 
’5^ tion Conf., Mar. 12-15, Glasgow, Scot¬ 
land. Contact Gordon Adshead, ICL, 26 Al¬ 
bany St., Edinburgh, EH1 3QH, UK, phone 44 
(31) 557-2478. 

IEEE Computer Society 1990 Int'l 
Conf. on Computer Languages, Mar. 
12-16, New Orleans. Contact Boumediene 
Belkhouche, Computer Science Dept., Tulane 
Univ., PO Box 5079, 301 Stanley Thomas Hall, 
New Orleans, LA 70118, phone (504) 865- 
5840. 

1990 Symp. on Interactive 3D Graphics, 

Mar. 18-21, Snowbird, Utah. Sponsors: US 
Office of Naval Research et al. Contact Rich 
Riesenfeld, Univ. of Utah, Computer Science 
Dept., 3190 Merrill Engineering Bldg., Salt 
Lake City, Utah 84112, phone (801) 581-8224. 

IPCCC, Ninth IEEE Int’l Phoenix Conf. on 
Computers and Communications, Mar. 21- 

23, Scottsdale, Ariz. Cosponsor: IEEE Com¬ 
munications Society. Contact Forouzan Gol- 
shani. Computer Science Dept., Arizona State 
Univ., Tempe, AZ 85287, phone (602) 965- 
2855. 

/TN ICSE 12,12th Int’l Conf. on Software 
Engineering, Mar. 26-30, Nice, France. 
Cosponsors: ACM, AFCET. Contact Francois- 
Regis Valette, CERT/DERI, PO Box 4026-2, 
Ave. Edouard Belin-31055 Toulouse, France, 
phone (33) 61-55-71-11; ICSE 12, AFCET, 

156 Bd. Pereire, 75017 Paris, France; or IEEE 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

1990 Int’l Conf. on Extending Data- 
base Technology, Mar. 26-30, Venice, 
Italy. Cosponsors: EDBT Foundation et al. 
Contact Michael L. Brodie, Intelligent Data¬ 
base Systems Dept., GTE Labs, 40 Sylvan Rd., 
MS 62, Waltham, MA 02254, phone (617) 466- 
2256. 


1990 AAAI Spring Symp. on the Theory and 
Application of Minimal-Length Encoding, 
Mar. 27-29, Stanford, Calif. Contact Edwin 
Pednault, AT&T Bell Laboratories, Rm. 4F- 
611, Crawfords Comer Rd., Holmdel, NJ 
07733, phone (201) 949-1074. 


April 1990 


CHI 90, Human Factors in Computing Sys¬ 
tems 1990, Apr. 1-5, Seattle. Sponsor: ACM. 
Contact Assoc, for Computing Machinery, 11 
W. 42nd St., New York, NY 10036. 

Fourth Parallel Processing and Neu- 
^*5' ral Network Symp., Apr. 3-5, Fuller¬ 
ton, Calif. Cosponsor: California State Univ. at 
Fullerton. Contact Larry H. Canter, c/o Com¬ 
puter Systems Approach, 1140 S. Raymond 
Ave., Suite B., Fullerton, CA 92631, phone 
(714) 738-3414. 

Flairs 90, Florida Al Research Symp., Apr. 
3-6, Cocoa Beach, Fla. Contact Avelino J. 
Gonzalez, Computer Engineering Dept., Univ. 
of Central Florida, Orlando, FL 32816, phone 
(407) 281-5027. 

1990 Symp. on Applied Computing, 
'5jJ' Apr. 5-6, Fayetteville, Ark. Cosponsors: 
Univ. of Arkansas, UA Student ACM Chapter. 
Contact Hal Berghel, Univ. of Arkansas, Com¬ 
puter Science Dept., Fayetteville, AR 72701, 
phone (501) 575-7343. 

Int’l Topical Meeting on Optical Com- 
'QJ' puting, Apr. 8-12, Kobe, Japan. Co¬ 
sponsors: SPIE et al. Contact S. Ishihara, Busi¬ 
ness Center for Academic Societies Japan, 3- 
23-1, Hongo, Bunkyo-ku, Tokyo 113, Japan, 
phone 81 (3) 817-5831. 

1990 IEEE VLSI Test Workshop, Apr. 
' 5 I 7 10-11, Atlantic City, NJ. Cosponsor: 
IEEE Philadelphia Section. Contact Wesley E. 
Radcliffe, IBM East Fishkill, Dept. 277, Bldg. 
321-5E1, Hopewell Junction, NY 12533, 
phone (914) 894-4346. 

Disco 90, Int’l Symp. on Design and Imple¬ 
mentation of Symbolic Computation Sys¬ 
tems, Apr. 10-12, Capri, Italy. Contact Al¬ 
fonso Miola, Dip. Informatica e Sistemistica, 
Via Buonarroti, 12, 00185 Roma, Italy, phone 
39 (6) 731-2367. 

Applications of Artificial Intelligence 
' 5 I 5 ' VIII, Apr. 15-18, Orlando, Fla. Spon¬ 
sor: SPIE. Contact Mohan M. Trivedi, Univ. of 
Tennessee, Electrical and Computer Engineer¬ 
ing, Ferris Hall, Knoxville, TN 37996-2100, 
phone (615) 974-5450. 

13th IEEE Workshop on Design for 
'^§5' Testability, Apr. 17-20, Vail, Colo. 
Contact T.W. Williams, IBM, PO Box 1900, 
Dept. 67 A/02 IB, Boulder, CO 80301-9191, 
phone (303) 924-7692. 

First Int’l Conf. on Systems Integra- 
*5^ tion, Apr. 23-26, Morristown, NJ. 
Sponsor: New Jersey Inst, of Technology. 
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Contact Peter A. Ng, Computer and Informa¬ 
tion Science Dept., New Jersey Inst, of Tech¬ 
nology, Newark, NJ 07102, phone (201) 596- 
3387. 


COIS 90, Conf. on Office Information 
5*7 Systems, Apr. 25-27, Cambridge, Mass. 
Sponsor: ACM. Contact Robert B. Allen, Rm. 
2A-367, Bellcore, 444 South St., Morristown, 
NJ 07960-1910, phone (201) 829-4280 or 
4315. 


First Int’l Symp. on Environments and 
Tools for Ada, Apr. 30-May 2, Redondo 
Beach, Calif. Cosponsor: ACM. Contact 
Stowe Boyd, Meridian Software Systems, 
23141 Verdugo Dr., Suite 105, Laguna Hills, 
CA 92653, phone (714) 727-0700, ext. 222; or 
Dewayne E. Perry, AT&T Bell Laboratories, 
600 Mountain Ave., Murray Hill, NJ 07974, 
phone (201) 582-2529. 


SIGMetrics 90, May 22-25, Boulder, Colo. 
Sponsor: ACM. Contact Gary J. Nutt, Univ. of 
Colorado, Boulder, CO 80301; or Herb 
Schwetman, MCC, 3500 W. Balcones Center 
Dr., Austin, TX 78759, phone (512) 338-3428. 

20th Int’l Symp. on Multiple-Valued 

Logic, May 23-25, Charlotte, N.C. Con¬ 
tact George Epstein, Computer Science Dept., 
Univ. of North Carolina at Charlotte, 214 Ken¬ 
nedy Bldg., Charlotte, NC 28223, phone (704) 
547-4566; or Carolyn F. Blalock, Office of 
Continuing Education, Univ. of North Caro¬ 
lina at Charlotte, Charlotte, NC 28223, phone 
(704) 547-4861. 

ICCI 90, Int’l Conf. on Computing and In¬ 
formation, May 23-26, Niagara Falls, Can¬ 
ada. Sponsor: Natural Sciences and Engineer¬ 
ing Research Council of Canada. Contact Wal- 
demar W. Koczkodaj, ICCI 90, Laurentian 
Univ., CoSc, Sudbury, Ont., Canada P3E 2C6. 


search, 755 College Rd. East, Princeton, NJ 
08540, phone (609) 734-6550. 


1990 European Simulation Multiconfer¬ 
ence, June 10-13, Erlangen, Federal Republic 
of Germany. Sponsor: SCS Int’l. Contact 
Bemd Schmidt, Univ. Erlangen, Computer 
Science Dept., D-8520, Erlangen, FRG, phone 
(49) 9131-857-278. 


IFIP Workshop on Design and Test of 
5*7 ASICs, June 11-12, Hiroshima, Japan. 
Cosponsors: IPSJ et al. Contact Kozo 
Kinoshita, Hiroshima Univ., 1-1-80 Higashis- 
endacho, Naka-ku, Hiroshima-shi 730, Japan, 
81 (87) 249-9150. 


19th Mumps Users’ Group Meeting, June 
11-15, Orlando, Fla. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 100, College 
Park, MD 20740, phone (301) 779-6555. 


May 1990 


10th IEEE Symp. on Mass Storage Sys- 
'5*7 terns. May 6-10, Monterey, Calif. Con¬ 
tact Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268. 

/gfa CompEuro 90, IEEE Int’l Conf. on 
'5*7 Computer Systems and Software En¬ 
gineering, May 7-9, Tel Aviv. Cosponsors: 
IEEE Region 8, IEEE Israel Section, IEEE 
Computer Society Israel Chapter. Contact 
CompEuro 90 Conf. Secretariat, c/o ORTRA, 2 
Kaufman St., PO Box 50432, Tel Aviv, 61500, 
Israel, phone 972 (3) 664-825. 

1990 IEEE Symp. on Research in Se- 
5^ curity and Privacy, May 7-9, Oakland, 
Calif. Contact Deborah Downs, Aerospace 
Corp., MS: M8/055, 2350 E. El Segundo Blvd., 
El Segundo, CA 90245-4691, phone (213) 
336-3052. 


1990 American Control Conf., May 23-25, 
San Diego, Calif. Sponsor: American Auto¬ 
matic Control Council. Contact Dagfinn 
Gangsaas, Boeing Advanced Systems, PO Box 
3707, MS 33-12, Seattle, WA 98124-2207, 
phone (206) 241-4348. 

17th Int’l Symp. on Computer Archi- 

tecture. May 28-31, Seattle. Cosponsor: 
ACM. Contact Jean L. Baer or Larry Snyder, 
Univ. of Washington, Computer Science 
Dept., FR-35, Seattle, WA 98195, phone (206) 
543-1695. 

ICDCS 10, 10th Int’l Conf. on Distrib- 
5*7 uted Computing Systems, May 28- 
June 1, Paris. Cosponsor: INRIA. Contact R. 
Popescu-Zeletin, GMD-FOKUS, Harden- 
bergplatz 2, D-1000 Berlin 12, West Germany, 
phone 49 (30) 25499-206; Jack Stankovic, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-0720; or ICDCS 10, TFFF 
Computer Society, 1730 Massachusetts Ave. 
NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


Fourth Int’l Symp. on Knowledge Engineer¬ 
ing, May 7-11, Barcelona, Spain. Sponsor: 
Madrid Polytechnic Univ. Contact Jose R. 
Chelala. ISKE, Alvarez de Baena, 3-2, 28006 
Madrid, Spain. 


1990 SID Int’l Symp., May 14-18, Las Vegas. 
Contact Howard L. Funk, IBM Corp., 10/641 
3B-60, Old Orchard Rd.,Armonk, NY 10504, 
phone (914) 765-6409. 


43rd SPSE Conf., May 20-25, Rochester, 
N.Y. Sponsor: Society for Imaging Science 
and Technology. Contact Michael M. Shahin, 
Xerox Corp., Webster Research Center, 800 
Phillips Rd., 0114-38D, Webster, NY 14580, 
phone (716) 422-2011. 


£2^ First Conf. oi 

5*7 medical Computing, May 22-25, At¬ 
lanta. Cosponsors: Nat’l Science Foundation 
et al. Contact Norberto Ezguerra, Bioengineer¬ 
ing Center, Georgia Tech, Atlanta, GA 30332, 
phone (404) 894-7026 or 3964. 


11th Conf. of the Canadian Applied Mathe¬ 
matics Society, May 29-June 1, Halifax, N.S., 
Canada. Cosponsors: CAMS et al. Contact 
Mary Meidell, Continuing Education Dept., 
Technical Univ. of Nova Scotia, PO Box 1000, 
Halifax, NS B3J 2X4, Canada, phone (902) 
429-8300, ext. 2420. 


June 1990 


IEEE Infocom 90, Ninth Conf. on 
5*7 Computer Communications, June 3-7, 
San Francisco. Cosponsor: IEEE Communica¬ 
tions Society. Contact Infocom 90, IEEE Com¬ 
puter Society, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 

/gS Workshop on Rapid System Prototyp- 
^7 ing, June 5-7, Raleigh, N.C. Contact 
Kenneth Anderson, Siemens Corporate Re- 


Ninth Int’l Conf. on Analysis and Optimiza¬ 
tion of Systems, June 12-15, Antibes, France. 
Sponsor: INRIA. Contact Conf. Secretariat, 
INRIA, Service des Relations Exterieures, 
Domaine de Voluceau — BP 105, 78153 Le 
Chesnay Cedex, France, phone 33 (l)-39-63- 
5500. 


IAPR Workshop on Syntactic and Struc¬ 
tural Pattern Recognition, June 13-15, Mur¬ 
ray Hill, N.J. Sponsor: Int’l Assoc, for Pattern 
Recognition. Contact Henry S. Baird, AT&T 
Bell Laboratories, Rm. 2C-557, 600 Mountain 
Ave., Murray Hill, NJ 07974, phone (201) 582- 
5744. 


Third Int’l Symp. on Image Conservation, 
June 17-20, Rochester, N.Y. Sponsor: Society 
for Imaging Science and Technology. Contact 
Charlton Bard, 74 Cornwall Lane, Rochester, 
NY 14617, phone (716) 342-3174. 


10th Int’l Conf. on Pattern Recogni- 
5*7 tion, June 17-21, Atlantic City, NJ. Con¬ 
tact Herbert Freeman, CAIP Center, 605 Hill, 
Rutgers Univ., New Brunswick, NJ 08903, 
phone (201) 932-4208. 


Seventh Int’l Conf. on Testing Computer 
Software, June 18-21, San Francisco. Contact 
Genevieve Houston-Ludlam, ISTC 90, c/o 
Frontier Technologies, 190 Admiral Cochran 
Dr., Suite 180, Annapolis, MD 21401, phone 
(301) 266-8244. 


Second Int’l Conf. on Software Engineering 
and Knowledge Engineering, June 21-23, 

Skokie, Ill. Sponsors: Knowledge Systems 
Inst., Univ. of Pittsburgh, and Inst, for Infor¬ 
mation Industries, Taiwan. Contact Shi-Kuo 
Chang, Computer Science Dept., Univ. of 
Pittsburgh, 322 Alumni Hall, Pittsburgh, PA 
15260, phone (412) 624-8490. 

NECC 90, 11th Nat’l Educational Comput¬ 
ing Conf., June 25-27, Nashville, Tenn. Spon¬ 
sor: Int’l Council for Computers in Education. 
Contact John D. McGregor, Computer Studies 
Dept., Murray State Univ., Murray, KY 42071, 
phone (502) 762-2614. 


COMPUTER 






DAC 90, 27th ACM/IEEE Design 
Automation Conf., June 25-29, 

Orlando, Fla. Contact Pat Pistilli, MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boulder, 
CO 80301, phone (303) 530-4333. 

Int’l Symp. on Fuzzy Approach to 
'Qj' Reasoning and Decision Making, June 
25-29, Bochyne, Czechoslovakia. Sponsor: 
Int’l Fuzzy System Assoc. Contact Vilem No¬ 
vak, Minin Inst., Czechoslovakia Academy of 
Sciences, A. Rimana 1768, 70800 Ostrava- 
Poruba, Czechoslovakia. 

/TN FTCS 20, 20th Int’l Symp. on Fault 
*50* Tolerant Computing, June 26-28, 

Newcastle upon Tyne, England. Cosponsors: 
Centre for Software Reliability, British Com¬ 
puter Society, IEE. Contact Neil Speirs, Com¬ 
puting Lab, Univ. of Newcastle upon Tyne, 
Newcastle upon Tyne, NE1 7RU, UK, phone 
44 (91) 232-8511. 

CGI 90, Computer Graphics Int’l 1990, 

June 26-30, Kent Ridge, Singapore. Sponsors: 
Computer Graphics Society, Inst, of Systems 
Science, Singapore. Contact Juzar Motiwalla, 
CGI 90, ISS, Nat’l Univ. of Singapore, Kent 
Ridge, Singapore 0511, phone (65) 772-2075. 


July 1990 


Second Int’l Symp. on Databases in 
'50' Parallel and Distributed Systems, July 
2-4, Dublin, Ireland. Cosponsor: ACM. Con¬ 
tact Rakesh Agrawal, AT&T Bell Labs, Rm. 
3D450, 600 Mountain Ave., Murray Hill, NJ 
07974, phone (201) 582-2250; or David Bell, 
Inst, of Informatics, Univ. of Ulster, Jordans- 
town. County Antrim, Northern Ireland 
BT370QB, phone (0232) 365-131. 

Second Int’l Conf. on Economics and 
*50 Artificial Intelligence, July 2-6, Paris. 
Sponsor: AFCET. Contact J-L. Le Moigne, 
GRASCE, Univ. Aix Marseille III, 3, ave. 
Robert Schuman, 13628, Aix en Provence, 
France; or P. Bourgine, 26, rue St. Louis, 
78000, Versailles, France. 


Iberamia 90, Second Ibero-American Conf. 
on AI, July 9-13, Morelia, Michoacan, Mex¬ 
ico. Sponsors: Centro Regional de Ensenanza 
en Informatica (Spain) et al. Contact Iberamia 
90, Am. Srita. Ma. Antonieta Alvarez Perez, 
Apartado Postal 70302, C.P. 04510, Mexico, 
D.F. 


Third Int’l Conf. on Industrial and 
'50' Engineering Applications for AI and 
Expert Systems, July 15-18, Charleston, S.C. 
Cosponsors: ACM et al. Contact Moonis Ali, 
Univ. of Tennessee Space Inst., MS15, Tulla- 
homa, TN 37388, phone (615) 455-0631. 


September 1990 


Electronic Publishing 90, Sept. 18-20, 

'50' Gaithersburg, Md. Sponsor: NIST. Con¬ 
tact Peter R. King, Computer Science Dept., 
Univ. of Manitoba, Winnipeg, Manitoba, Can¬ 
ada R3T 2N2, phone (204) 474-9935. 
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SOFTWARE ENGINEERS 


Tomorrow’s Computing 
Technology is Today’s Challenge 


I D A 


Some of the nation’s most exciting 
developments in software technol¬ 
ogy, supercomputer architecture, 
AI, and expert systems are under 
scrutiny right now at the Institute 
for Defense Analyses. IDA is a 
Federally Funded Research and 
Development Center serving the 
Office of the Secretary of Defense, 
the Joint Chiefs of Staff, Defense 
Agencies, and other Federal 
sponsors. 

IDA’s Computer and Software 
Engineering Division (CSED) is 
seeking professional staff members 
with an in-depth theoretical and 
practical background in software 
engineering tools, techniques, and 
theories. One emphasis of the Div¬ 
ision’s work is on defining, build¬ 
ing, and evaluating tools/envir¬ 
onments to support the entire 
software life-cycle of mission criti¬ 
cal computer based systems, 
focused on Ada and artificial intel¬ 
ligence environments. Tasks 
include efforts in prototyping 
tools/systems, testing and evaluat¬ 
ing support tools, advising major 
DoD programs on appropriate 
technologies, and assisting the 
DoD in defining advanced policies 
for software development and 
maintenance. 

Specific desired interests and skills 
include: 

• Formal representation of 
requirements and designs 

• Program verification, test and 
evaluation 

• Combined hardware/software 
system design methodologies 

• Transformational approaches to 
automated program generation 

• Software reusability and reuse 


• Software reliability/fault 
tolerance 

• Environment test and eval¬ 
uation (including assessing 
impacts on productivity and 
reliability) 

• Standards for environmental and 
operational software interfaces 

Specialists in other areas of Com¬ 
puter Science are also sought: Dis¬ 
tributed Systems, Artificial Intelli¬ 
gence and Expert Systems, 
Programming Language Experts 
and Computer Security Scientists. 

We offer career opportunities at 
many levels of experience. You 
may be a highly experienced indi¬ 
vidual able to lead IDA projects 
and programs ... or a recent 
MS/PhD graduate. You can 
expect a competitive salary, excel¬ 
lent benefits, and a superior pro¬ 
fessional environment. Equally 
important, you can expect a role 
on the leading edge of the state of 
the art in computing. If this kind 
of future appeals to you, we urge 
you to investigate a career with 
IDA. Please forward your resume 
to: 

Mr. Thomas J. Shirhall 
Manager of Professional Staffing 
Institute for Defense Analyses 
1801 N. Beauregard Street 
Alexandria, VA 22311 
An equal opportunity employer. 
U.S. Citizenship is required. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line. $120 
minimum charge (up to ten lines). 
Average five typeset words per line, eight 
lines per column inch. Add $10 for box 
number. Send copy at least one month 
prior to publication to: Heidi Rex or 
Marian Tibayan, Classified Advertis¬ 
ing, COMPUTER Magazine, 10662 Los 
Vaqueros Circle, Los Alamitos, CA 
90720; (714) 821-8380. 


THE AMERICAN UNIVERSITY 
IN CAIRO 

One Assistant, Associate, or Full Professor 
needed to teach, in English, undergraduate 
courses in Computer Science including 
theory of computing and design of algo¬ 
rithms. Ph.D. required. Rank, salary based 
on qualifications and experience. Two-year 
appointment (renewable) beginning Sep¬ 
tember 1990. For expatriates, housing, 
roundtrip air travel, plus schooling for two 
children included. Write with curriculum 
vitae to: Dean George H. Gibson, The 
American University in Cairo, 866 United 
Nations Plaza, Suite 517, New York, New 
York 10017, preferably before December 
15. 


SYRACUSE UNIVERSITY 
Department Chair, Electrical 
and Computer Engineering 

The department of Electrical and Com¬ 
puter Engineering at Syracuse University is 
seeking nominations and applications for the 
position of department Chair. Applications 
received by December 31, 1989, will receive 
full consideration. The appointment is to be 
made by July 1, 1990. The qualifications de¬ 
sired include: a doctorate in either electrical 
or computer engineering, a strong commit¬ 
ment to teaching and curriculum develop¬ 
ment at both the graduate and undergradu¬ 
ate levels, a distinguished record in research 
and scholarly publications, and demonstrated 
leadership and administrative abilities. The 
department consists of 45 faculty members 
and awards 100 BS, 200 MS, and 25 PhD 
degrees annually. Active areas of research in¬ 
clude a wide spectrum of electrical and com¬ 
puter engineering disciplines, with an annual 
research budget for salaries of over $4 million. 
Department faculty are actively engaged in re¬ 
search with the New York State Center for 
Advanced Technology in Computer Applica¬ 
tions and Software Engineering, the North¬ 
east Parallel Architectures Center, the North¬ 
east Artificial Intelligence Consortium, and the 
Institute for Energy Research. Applications 
and nominations should be submitted to Pro¬ 
fessor John Brule, Chair Search Committee, 
Department of Electrical and Computer Engi¬ 
neering, Syracuse University, Syracuse New 
York, 13244-1240, (315) 443-4417. Syra¬ 
cuse University is an Affirmative Action/Equal 
Opportunity Employer. 


UNIVERSITY OF MISSOURI- 
COLUMBIA 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
tenure-track positions at the assistant, associ¬ 
ate or full professor level in the areas of com¬ 
puter vision, image processing, artificial intel¬ 
ligence and neural networks. Responsibilities 
include teaching undergraduate and gradu¬ 
ate courses, student advising, and develop¬ 
ing and conducting sponsored research pro¬ 
grams. Candidates must have an earned 
doctorate in Electrical and Computer Engi¬ 
neering, Computer Science or related disci¬ 
pline, and the potential for, and commitment 
to, developing sponsored research. The 
department currently has strong research 
programs in computer vision/pattern recog¬ 
nition, materials and solid state, and power 
electronics. Interested applicants should 
send a resume, a description of teaching and 
research interests and a list of three 
references to: John Meese, Chairman, De¬ 
partment of Electrical and Computer Engi¬ 
neering, University of Missouri-Columbia, 
Columbia, Missouri 65211. Immigration 
status of non-United States Citizens should 
be stated. Affirmative Action/Equal Oppor¬ 
tunity Employer. 


PURDUE UNIVERSITY 
Computer Engineering 
Faculty Positions 

The School of Electrical Engineering at 
Purdue University seeks outstanding candi¬ 
dates in all areas of Computer Engineering 
for research and teaching. Openings are for 
tenure-track faculty at all levels. Active 
research areas include artificial intelligence 
and expert systems; computer communica¬ 
tion networks; computer vision; design 
automation tools; digital signal processor 
system design; distributed algorithms and 
databases; fault-tolerant and testable com¬ 
puting; microprocessor design; neural net¬ 
works; parallel processing (architecture, 
algorithms, operating systems, compiling, 
languages, interconnection networks, and 
performance); robot vision, sensors and 
control; software engineering; speech pro¬ 
cessing; and VLSI architecture. 

The School has 68 full-time faculty (25 in 
Computer Engineering), and over $9M in 
funded research projects. In addition to the 
Ph.D., MSEE, and BSEE degrees, the 
School offers a BSCEE (Bachelor of Sci¬ 
ence in Computer and Electrical Engineer¬ 
ing) which is accredited in both Computer 
Engineering and Electrical Engineering. 
Computing facilities available to the faculty 
include the Engineering Computer Net¬ 
work (including 13 VAX 11/780’s running 
UNIX BSD 4.3, 1 Gould PN 9080,4 Gould 
NP l’s, a CCI PN 6/32, and 255 Sun work¬ 
stations) , the Computing Center’s Cyber-205 
and ETA-10 supercomputers, a Symbolics 
LISP machine, and IBM 3090/180E, exten¬ 
sive graphics facilities, and numerous PC’s. 


Parallel computing facilities include a 128- 
node Ncube hypercube, a 48 X 48 processor 
NCR-GAPP processor array, a 16 processor 
Transputer array, the 30-processor PASM 
Parallel Processor prototype that was devel¬ 
oped and built at Purdue, and the Com¬ 
puting Center’s Sequent Balance 21000. 
Custom VLSI chip facilities include an IBM 
Master Image System. Equipment in the 
Robot Vision Lab and Computer Vision and 
Image Processing Lab includes a Puma 762 
robot, a Cincinnati Milacron T3-726 robot, a 
K2A Cybermation mobile robot, and Gould/ 
DeAnza, Comtql, Grinnell, and Imaging 
Technologies image processing systems. 

Applicants must possess a doctorate 
degree. Send a resume, including a state¬ 
ment of teaching and research interests and 
a list of three (3) references, to: Head, 
School of Electrical Engineering, Purdue 
University, West Lafayette, IN 47907. Pur¬ 
due University is an Equal Opportunity/Af¬ 
firmative Action employer. 


YALE UNIVERSITY 
Postdoctoral Positions in 
Medical Image Analysis 

One to two positions are open within a re¬ 
search group interested in developing com¬ 
puter vision- and image understanding- 
based approaches to several medical image 
analysis problems. We are particularly in¬ 
terested in using model-based optimization 
strategies for locating and quantifying ana¬ 
tomical structure, and are in the process of 
extending these ideas to handle three-di¬ 
mensional and four-dimensional data sets 
now becoming available from several diag¬ 
nostic imaging modalities (including Mag¬ 
netic Resonance). The group has 4 faculty 
members performing medical image proces¬ 
sing/image analysis research, 8 Ph.D. stu¬ 
dents and 2 full-time programmers. The 
positions are joint between the Departments 
of Diagnostic Radiology and Electrical Engi¬ 
neering. In addition, the research group has 
strong ties with faculty members in the Com¬ 
puter Science Department. Those who ap¬ 
ply should have a Ph.D. in Electrical Engi¬ 
neering or Computer Science, preferably 
with a strong programming background and 
some familiarity with, and course work in, 
image processing and computer vision. The 
initial appointment will be for one year, re¬ 
newable for a second year contingent upon 
the availability of funds and by mutual agree¬ 
ment. Salary will be based on background 
and experience, but is expected to be in the 
$28K-$32K range. Review of applications 
will begin immediately and will be accepted 
until the positions are filled. Applicants 
should send a resume and the names and 
addresses of three references to: Professor 
James Duncan, Departments of Diagnostic 
Radiology and Electrical Engineering, Yale 
University, 333 Cedar Street (327BML), 
New Haven, Connecticut, 06510, and/or 
contact him at Duncan@venus.ycc.yale.edu. 
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SOFTWARE TECHNICIAN 
(SOFTWARE ENGINEER) 

Analyze competitive products and 
develop software algorithms for improve¬ 
ment of company product. Require M.Sc. 
Computer Science, proficiency in C, rela¬ 
tional database theory, SQL; minimum of 
two graduate courses in design and analysis 
of data structures for main memory data 
bases, or research project with thesis or 
published paper demonstrating such knowl¬ 
edge. Use C, Assembly, SQL, ENABLE. 
$30,000/yr. F/T, overtime required. AA/ 
EOE. Submit resume, 3 academic or profes¬ 
sional references to: Saratoga Springs Job 
Service, Attn: Thomas Prout, 10 Division 
Street, Saratoga Springs, NY 12866. Refer 
to Job Order 0403243 D.O.T. Code 020. 
262-010. 


UNIVERSITY OF MINNESOTA 

University of Minnesota Department of 
Electrical Engineering has several tenure 
track or tenured faculty positions in Electrical 
Engineering available at all levels. The duties 
will include the establishment of sponsored 
research and undergraduate and graduate 
teaching. Applications from individuals with 
exceptional qualifications in all areas of Elec¬ 
trical Engineering will receive due considera¬ 
tion. Of particular interest, however, are 
specialities in computer architecture and 
digital electronics, microelectronics, circuits 
and VLSI design, magnetics, image process¬ 
ing and computer vision. 

The Department of Electrical Engineering 
has 45 faculty members providing under¬ 
graduate and graduate education and pursu¬ 
ing research in all areas of electrical engineer¬ 
ing. The State-funded Microelectronics and 
Information Sciences Center and Super¬ 
computer Institute at the University of Min¬ 
nesota will provide opportunities for inter¬ 
disciplinary research in cooperation with 
industry. The Department has a complete in¬ 
tegrated circuit fabrication and design lab. 
access to Cray supercomputers, and other 
facilities. 

The requirements include an earned Doc¬ 
torate and outstanding academic and re¬ 
search records. Rank and salary will be 
commensurate with qualifications and ex¬ 
perience. Temporary and visiting positions 
are also available. Send applications and 
resumes to: 

Professor Mostafa Kaveh, Chairman of 
the Faculty Recruiting Committee 

Department of Electrical Engineering, 
University of Minnesota 

200 Union Street Southeast, Minneapolis, 
MN 55455 

Last date for receiving applications August 
30, 1989, for positions available September 
16, 1990. Review and interviews may begin 
as early as November 15, 1989, and early 
decisions may be made on some positions. 

The University of Minnesota is an equal 
opportunity educator and employer and 
specifically invites and encourages applica¬ 
tions from women and minorities. 


CARNEGIE MELLON UNIVERSITY 
Faculty Positions in 
Computer-Aided Engineering 


Carnegie Mellon University, Department 
of Civil Engineering, invites applications for 
(1) tenure-track position at the rank of Assis¬ 
tant Professor or above, and (1) visiting 
faculty position in the area of Computer- 
Aided Engineering (CAE). The tenure-track 
position will begin either January or Septem¬ 
ber, 1990. The visiting position runs from 
January thru December, 1990, and may be 
filled by two individuals, one from January 
through May 15, and one from August 15 
through December. Candidates for either 
position must have an earned Ph.D. (or 
equivalent experience for the visiting posi¬ 
tion), with research and educational em¬ 
phasis on CAE, in civil engineering. The De¬ 
partment offers programs in CAE, engineer¬ 
ing planning and management (including 
construction automation), environmental 
engineering, and structural mechanics. 
Within CAE, areas of special interest include 
artificial intelligence, knowledge-based sys¬ 
tems, database management, parallel com¬ 
putations, design methodology, graphics, 
user-interfaces, visualization, geometric 
modeling and large-scale systems design. 


Candidates for the tenure-track position 
should also have interests in one of the other 
areas of the department. Those with interests 
in planning and management or environmen¬ 
tal engineering are especially encouraged to 
apply. Tenure-track responsibilities include 
teaching of undergraduate and graduate 
courses in CAE and other areas of civil engi¬ 
neering, advising students, developing curri¬ 
culum, supervising research and graduate 
students, and establishing a funded research 
program. Visiting faculty will teach 1 course 
per semester in CAE and participate in on¬ 
going research activities. CAE activities are 
well established, and the department offers 
excellent facilities and opportunities for pro¬ 
fessional and intellectual growth. The de¬ 
partment maintains close ties with the uni¬ 
versity’s Robotics Institute, the School of 
Computer Science and with the CMU Engi¬ 
neering Design Research Center. Send ap¬ 
plication with curriculum vita and names of 
at least three references to: Daniel R. Rehak, 
CAE Faculty Search Committee, Depart¬ 
ment of Civil Engineering. Carnegie Mellon 
University, Pittsburgh, PA 15213-3890. IN¬ 
TERNET: REHAK@CE.CMU.EDU. Clos¬ 
ing date for applications is October 1, 1989, 
or until the position is filled. Carnegie Mellon 
is an equal opportunity/affirmative action 
employer. 


Scientists & Engineers 


SOLVE REAL-WORLD PROBLEMS 

FROM FIRST PRINCIPLES 


Few challenges today come with 
ready-made answers. Add the complex¬ 
ity of high technology and the possibili¬ 
ties multiply. As the central research 
facility for Martin Marietta Corporation, 
Martin Marietta Laboratories is solving 
some of the toughest problems around 
in automatic target recognition (ATR), 
neural networks and process control. 
SCIENTISTS—NEURAL NETWORKS 
Due to expansion in neural networks 
research, scientists are needed in adap¬ 
tive learning and development of neural 
network models. Applications include 
computer vision, advanced ATR, sensor 
data interpretation and fusion, and 
adaptive control. 

Requires MS or PhD with 2-3 years 
background in computer science, algo¬ 
rithm development, and software sim¬ 
ulation of neural networks. Knowledge 
and experience in parallel (especially 
systolic array) processing is a plus. 


Requires MS or PhD in Engineering or 
Computer Science with at least three 
years experience and familiarity with 
UNIX, C, and computer graphics. Areas 
of expertise should include modeling 
and simulation, process control, data 
fusion, statistical analysis and decision 
theory, and artificial intelligence. 

We are conveniently located on a 
campus-llike setting between Baltimore, 
MD and Washington, D.C. Beyond out¬ 
standing professional challenge and 
opportunity, we offer a competitive sal¬ 
ary and benefits program including tui¬ 
tion reimbursement for advanced study. 
Send resume to: 

Beth Snyder Jones 
Personnel Recruiter 
Martin Marietta Laboratories 
1450 South Rolling Road 
Baltimore, MD 21227 
(301) 247-0700, ext. 2331 


SENIOR ENGINEER—PROCESS 
CONTROL 

Senior engineer needed to lead 
research activities in process modeling 
and control, sensor interpretation for 
industrial applications, artificial intelli¬ 
gence, and machine learning. 




MARTIN MARIETTA LABORATORIES 
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STANFORD UNIVERSITY 
Programmer 
Systems Programmer III 

Academic Information Resources is seek¬ 
ing a VM Systems Programmer responsible 
for maintaining and managing 2 IBM 4381- 
14 computers running VM/HPO, VM/XA, 
and a range of 3rd party applications soft¬ 
ware. Responsibilities include developing, 
recommending, and monitoring system con¬ 
figuration, software services, network ser¬ 
vices, and load distribution between the VM 
systems; installing, maintaining, and devel¬ 
oping operating system, utility, and applica¬ 
tions software; and recruiting, training, and 
supervising student programming staff. 

Qualifications include a degree in Com¬ 
puter Sciences or related field, 3+ years of 
solid experience installing and maintaining 
operating system software and program 
products on VM/HPO and VM/XA; or 
equivalent combination of education and ex¬ 
perience. Experience in an academic en¬ 
vironment preferred. Knowledge of CP and 
CMS internals; TCP/IP networks and net¬ 
work services; Sun Micro’s Open Network¬ 
ing Computer protocols and software; and 
4.3 BSD operating system. Experience pro¬ 
gramming in REXX and IBM 370 assembler; 
maintaining 3rd party software—SAS, 
SPSS-X, BMDP, IMSL and others; and 
working with a variety of program lan¬ 
guages, especially C. Demonstrated skills in 
organizational and project management; 
working with diverse groups; and written 
and oral communication. 

Send resume and cover letter highlighting 
qualifications to: Jose V. Becerra, *52232- 
IEEE, Stanford Human Resources Services, 
855 Serra St., Stanford, CA 94305-6110. 
An equal opportunity employer through af¬ 
firmative action. 


THE UNIVERSITY OF 
SOUTH FLORIDA 
The Center for 
Microelectronics Research 

The Center for Microelectronics Research 
(CMR) at the University of South Florida is 
seeking graduate research assistants to sup¬ 
port research activities in the areas of elec¬ 
tronic materials, semiconductor processing 
and characterization, and VLSI integrated 
circuit design and test. Successful applicants 
will be required to pursue a Ph D. Program 
in the Electrical Engineering, Computer Sci¬ 
ence and Engineering, or Physics Depart¬ 
ment. Stipends are available in the range of 
$12K to $16K (half time) for a full calendar 
year, with tuition waivers, and medical in¬ 
surance cost reimbursement also available. 
Applicants must have an excellent academic 
record and are expected to have earned a 
minimum of a Bachelors degree in Electrical 
Engineering, Computer Science, Physics, or 
a related engineering discipline. Successful 
applicants must be capable of performing 
directed research in either of three areas: (1) 
electronic materials and semiconductor pro¬ 
cessing, (2) Integrated curcuit design, or (3) 
integrated curcuit test. Candidates are also 
expected to have sound communication 
.skills, both verbal and written. Positions will 
be awarded on a competitive basis, with 


equal preference to out-of-state candidates. 
Special consideration will be given to can¬ 
didates with relevant industrial research ex¬ 
perience. The Center for Microelectronics 
Research is a state funded research center 
which is part of the College of Engineering at 
USF, and is currently housed in a new $10M 
engineering building. A new electronic 
materials laboratory is currently under 
development to house recently purchased 
processing and characterization equipment, 
to include lithographic tools with deep UV 
exposure capability, conventional furnaces, 
LPCVD and PECVD tools, plasma and RIE 
etch systems, as well as afterglow and ECR 
systems, and a sputter tool with conventional 
and reactive sputtering capability. A variety 
of material characterization tools such as an 
FTIR/Raman spectrometer, an emission 
spectrometer, and a research ellipsometer 
have also been acquired. This is comple¬ 
mented by an integrated curcuit design la¬ 
boratory with more than ten Sun 3/60 work¬ 
stations, a color Versatec plotter, and a 
complete suite of commercial computer- 
aided design tools from Cadence Design 
Systems, CADAT, HILO, and others. A 
high performance integrated circuit test 
system is currently being procured. Research 
funding at CMR this year totals over $8M, 
with primary support coming from state and 
DOD funding sources, including a signifi¬ 
cant, multi-year research project in wafer 
scale integration sponsored by the Defense 
Advanced Research Projects Agency. Op¬ 
portunities exist for extensive interactions 
with industry both within and outside the 
state of Florida. The University of South 
Florida is located in Tampa, one of the na¬ 
tion’s top growth areas with an expanding 
high technology industry base. The Universi¬ 
ty of South Florida is an affirmative action/ 
equal opportunity employer. Requests for 
applications and/or information should be 
directed to Kevin T. Wilson, Assistant Direc¬ 
tor, Center for Microelectronics Research, 
College of Engineering, University of South 
Florida, ENG 118, Tampa, FL 33620. 


FLORIDA ATLANTIC UNIVERSITY 

The College of Engineering at Florida 
Atlantic University is seeking applications for 
facility positions in the area of autonomous 
intelligent machines. The college is expand¬ 
ing its robotics and intelligent machine pro¬ 
gram to specifically address automous 
underwater vehicles and subsea robotics. 
The positions offer unique opportunities to 
develop new capabilities and fundamental 
disciplines of computing, visions, sensors, 
communications, controls, and A.I. Appli¬ 
cants should have a Ph.D. in Engineering or 
Computer Science with a demonstrated 
research background in the areas listed 
above. Interested persons should send a 
resume including a list of publications and 
funded research programs with which they 
have been associated to Dr. Stanley E. 
Dunn, Acting Dean of Engineering, College 
of Engineering, Florida Atlantic University, 
Boca Raton, FL 33431. Applications will be 
accepted through October 30th, 1989. FAU 
is an AA/EEO Employer. Women and mi¬ 
norities are encouraged to apply. Pending 
approval, we anticipate hiring 2 faculty and 
one engineer. 


WEST VIRGINIA UNIVERSITY 

The Department of Electrical and Com¬ 
puter Engineering at West Virginia Universi¬ 
ty seeks candidates for tenure-track faculty 
positions with research specializations in the 
following areas: operating systems, software 
engineering, database systems and artificial 
intelligence. Candidates should possess 
strong teaching qualifications in computer 
science. 

The Department of Electrical and Com¬ 
puter Engineering offers degree programs at 
the bachelor’s, master’s and doctoral levels. 
Departmental facilities include numerous 
workstations, several research and instruc¬ 
tional laboratories. The University supports 
computing with a network of IBM and VAX. 
In addition, Morgantown is situated in “Soft¬ 
ware Valley” and is also one hour south of 
the “Software Engineering Institute” in Pitts- 

Morgantown is a very pleasant place in 
which to live and work while the cost of living 
is rather low. The city has many cultural and 
sporting activities available. West Virginia 
was recently rated as having the lowest crime 
rate in the nation. 

Rank and salary will depend on qualifica¬ 
tions. Applicants should send a cover letter 
stating specific area of specialization and a 
curriculum vitae with names and address of 
at least three references to: Dr. Ronald L. 
Klein, Chairman, Department of Electrical 
and Computer Engineering, West Virginia 
University, P.O. Box 6101, Morgantown, 
WV 26506-6101. 

Women, minorities and members of other 
protected groups are strongly encouraged to 
apply. West Virginia University is an Equal 
Opportunity/Affirmative Action Employer. 


UNIVERSITY OF CALIFORNIA, 
SANTA BARBARA 

University of California, Santa Barbara, 
Electrical and Computer Engineering. Appli¬ 
cations are invited for at least four tenure- 
track faculty positions, available effective 
7/1/90, for candidates experienced in im¬ 
age processing/computer vision/speech 
processing, parallel algorithms, CAD/Solid- 
State, control systems, and computer engi¬ 
neering. The positions start at the rank of 
Assistant Professor, although higher level 
appointments are possible for individuals 
with outstanding records. Normally comple¬ 
tion of a doctorate is required at the time of 
the appointment. Candidates should have 
outstanding research potential or a distin¬ 
guished research reputation, the ability to at¬ 
tract external research funding, and a strong 
commitment to teaching at the undergradu¬ 
ate and graduate levels. Applicants should 
send their resumes and the names and ad¬ 
dresses of at least four professional refer¬ 
ences to: Faculty Search Committee, Depart¬ 
ment of Electrical and Computer Engineering, 
University of California, Santa Barbara, CA 
93106. Applications will be received until the 
positions are filled. Proof of U.S. Citizenship 
or eligibility for U.S. employment will be re¬ 
quired prior to employment (Immigration 
Reform and Control Act of 1986). An Equal 
Opportunity/Affirmative Action employer. 
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STATE UNIVERSITY OF NEW YORK 
AT BUFFALO 

Department of Computer Science 
Faculty Positions 

Applications are invited for tenure-track 
faculty positions at all levels, to begin Fall 
1990. Applicants for the Assistant Professor 
level must demonstrate superior research 
and scholarship potential, and have a Ph.D. 
in computer science or a related field awarded 
by September 1, 1990. Applicants for senior 
positions must have an exceptional record of 
research achievement. 

The University at Buffalo is the most com¬ 
prehensive public university in New York 
and New England. The department current¬ 
ly has 14 tenure-track faculty, 3 lecturers and 
9 research and adjunct faculty. There are ap¬ 
proximately 130 Ph.D. and M S. students 
and 200 selectively admitted B.A./B.S. 
majors. The department is expanding, with 
additional faculty lines committed annually 
and a new building under construction. 
Salaries are extremely competitive. 

Primary research areas include: artificial 
intelligence, computer vision, parallel algo¬ 
rithms, numerical linear algebra, theory of 
computation, programming languages and 
performance evaluation. Department mem¬ 
bers are actively engaged in interdisciplinary 
research programs in Advanced Scientific 
Computing, Cognitive Science, Vision, and 
the NSF National Center for Geographic In¬ 
formation and Analysis. Departmental com¬ 
puting facilities include an Encore multimax, 
a Vax 11/785, Hypercubes, Sun worksta¬ 
tions, Symbolics Lisp Machines, various im¬ 
age processing/graphics systems, micro- 
based teaching laboratories, and ready ac¬ 
cess to university-wide computing facilities. 

Resumes and names of four references 
should be directed to: Dr. Deborah Walters, 
Chair of Search Committee, Department of 
Computer Science, 226 Bell Hall, SUNY at 
Buffalo, Buffalo, NY 14260. Net Address: 
walters@cs.buffalo.edu. For full considera¬ 
tion applications should be received by Janu¬ 
ary 1, 1990. SUNY is an Equal Oppor¬ 
tunity/Affirmative Action employer. 


THE FLINDERS UNIVERSITY OF 
SOUTH AUSTRALIA 

New Computer Science Initiatives 
Foundation Chair and other 
Academic Posts 

The Flinders University of South Australia 
is in the process of greatly expanding its 
Discipline of Computer Science to include a 
Foundation Chair, an Associate Professor¬ 
ship and four lectureship positions. 

Concurrently the University is establishing 
a National Centre for Software Engineering 
in partnership with the Institute of Informa¬ 
tion and Communications Technologies of 
the Commonwealth Scientific and Industrial 
Research Organization (CSIRO). 

The expanded Discipline of Computer 
Science aims to attract above average levels 
of external funding and collaboration. Dis¬ 
cussions on joint ventures with major inter¬ 
national computer companies are also in 
train as a result of recent Federal Govern¬ 
ment initiatives to encourage such external 
funding. 

The Computer Science and Software 


Engineering developments will be housed in 
a new purpose-designed building for Infor¬ 
mation Sciences costing in excess of $6 
million that will be constructed next year. 

Discussions are also proceeding with the 
South Australia Institute of Technology on 
the formation of a new Faculty or Centre of 
Information Science and Technology based 
on existing strengths of the two institutions in 
computing, mathematics, cognitive science, 
electronic engineering, digital systems engi¬ 
neering, logic, information systems and 
other cognate disciplines. 

The FOUNDATION CHAIR OF COM¬ 
PUTER SCIENCE is one of six academic 
positions to be filled. Together with the ex¬ 
isting nine academic staff, and six supporting 
staff, the incoming professor will have the 
opportunity to develop a dynamic group that 
would be at the core of the University’s new 
initiatives in the field of Information Science 
and Technology. 

The University is seeking applications 
from appropriately qualified persons who 
have the vision and commitment to develop 
a discipline of computer science attuned both 
to the rapidly changing needs of Australia 
and to the challenges of fundamental devel¬ 
opments in information science and technol¬ 
ogy. The incoming professor will have the 
opportunity to shape the further develop¬ 
ment of the discipline through appropriate 
appointments. 

Base salaries of the position are: 


Professor A$63,919 

Associate Professor A$54,192 

Lecturer A$31,259 

The closing date for applications will be 
Friday, 27 October 1989. 

Supplementary benefits include provision 
for superannuation, leave (outside studies) 
and travel expenses. It is University policy to 
negotiate additional special loadings when 
these are justified by market forces. The 
University also encourages academic staff to 
undertake consulting and other professional 
activities relevant to their discipline within 
certain time limits. 

Applications should be made in writing to 
the Director of Administration and Registrar, 
The Flinders University of South Australia, 
Bedford Park SA 5042, and should contain 
the names and address of three referees 
from whom confidential assessments can be 
obtained. Expressions of interest are also 
sought. The University reserves the right to 
fill the Chair by invitation. 

Further written information on the posi¬ 
tions can be obtained from the Manager of 
Human Resources Division, telephone 
(+ 61-8) 275 2300, fax (+ 61-8) 276 8213. 

The following are available to discuss any 
enquiries: 

Professor L.B. Geffen, Pro-Vice-Chan- 
cellor: Tel. ( + 61-8) 275 2683 

Associate Professor M. J. Brooks, Head of 
Computer Science: Tel. (+ 61-8) 275 2662; 
electronic mail mjb@cs.flinders.oz.au. 



KING FAHD UNIVERSITY OF 
PETROLEUM & MINERALS 
DHAHRAN 31261, 

SAUDI ARABIA 


COMPUTER ENGINEERING DEPARTMENT 

THE DEPARTMENT OF COMPUTER ENGINEERING SEEKS APPLICATIONS 
FOR FACULTY POSITIONS AT ALL LEVELS. APPLICANTS MUST HOLD A PH.D. 
DEGREE IN COMPUTER ENGINEERING OR RELATED AREAS. INDIVIDUALS 
WITH RESEARCH INTERESTS IN ONE OR MORE OF THE FOLLOWING 
AREAS ARE PREFERRED: FAULT TOLERANT COMPUTING, COMPUTER 
ARCHITECTURE, MICROPROCESSORS AND COMPUTER BASED SYSTEMS, 
COMPUTER NETWORKS, DATA COMMUNICATIONS, DIGITAL SYSTEM 
DESIGN, VLSI, AND DESIGN AUTOMATION. DEPARTMENT LABS INCLUDE 
DESIGN AUTOMATION, DIGITAL DESIGN, MICROPROCESSOR SYSTEMS, 
AND ROBOTICS. TEACHING AND RESEARCH ARE SUPPORTED BY A 
VAX-11/780, A FULLY EQUIPPED GRAPHIC CENTER, AND A NUMBER OF 
MICROCOMPUTERS AS WELL AS A UNIVERSITY DPC THAT INCLUDES 
AMDAHL 5850 AND IBM 3090 MAINFRAMES. 

KFUPM offers attractive salaries commensurate with qualifications and experi¬ 
ence, and benefits that include free furnished air-conditioned accommodation 
on campus, yearly repatriation tickets, ten months duty each year with two months 
vacation salary. Minimum regular contract for two years, renewable. 

Interested applicants are requested to send their Curriculum Vitae with support¬ 
ing information not later than one month from the date of this publication, to: 

DEAN OF FACULTY AND PERSONNEL AFFAIRS 
KING FAHD UNIVERSITY OF PETROLEUM & MINERALS 
DEPT NO. COE/382-AP/01 
DHAHRAN 31261, SAUDI ARABIA 


October 1989 


103 










AUBURN UNIVERSITY 
Department Head 
Computer Science and 
Engineering Department 

The Computer Science and Engineering 
Department of Auburn University, Auburn, 
Alabama, invites applications for the position 
of department head. This position also in¬ 
cludes appointment at a professorial rank in 
the College of Engineering. Qualified per¬ 
sons with a Solid record of achievement and 
the desire to lead a growing, research- 
oriented department are encouraged to 
apply. 

The Department has eleven full-time 
faculty members and offers the Bachelor’s 
degree in both Computer Science and Com¬ 
puter Engineering, as well as the M.S. and 
Ph.D. degrees. The undergraduate program 
is both ABET and CSAB accredited. Depart¬ 
mental equipment includes a VAX 11/780, 
MicroVAX-Il, TI Explorers, Sun and Apollo 
workstations, and various PC’s; the majority 
of these are linked by a Department-wide 
Ethernet employing Internet protocol (TCP/ 
IP) and the Network File System (NFS). 
Campus-wide facilities include an IBM 3083, 
VAX 11/785, VAX 8200, VAX 8250 and a 
host of IBM PCs. In addition, Auburn is a 
member of the Alabama Supercomputer 
Network which includes a CRAY X-MP/24. 

The quality of life available in the Auburn 
Community is superb; it is a college-town at¬ 
mosphere and the city is strategically located 
close to several large metropolitan centers 
such as Atlanta and Montgomery. Salary is 
commensurate with education and experi¬ 
ence. Nominations and applications should 
be sent to J. David Irwin, Chairman, CSE 
Department Head Search Committee, Elec¬ 
trical Engineering Department, Auburn Uni¬ 
versity, AL 36849-5201. Minorities and 
women are encouraged to apply. Auburn 
University is an equal opportunity and affir¬ 
mative action employer. 


UNIVERSITY OF FLORIDA 

Applications are invited for visiting and 
tenure-track positions at all levels. Applicants 
must have strong research capability in one 
of the specialized areas and be able to teach a 
variety of courses in Computer and Informa¬ 
tion Sciences. Areas of special emphasis in¬ 
clude artificial intelligence, computer vision, 
distributed computing systems, parallel pro¬ 
cessing and software engineering. Positions 
are available for Spring 1990 as well as the 
1990-91 academic year. Each applicant must 
have a doctoral degree in Computer Science 
or a related area or will complete the degree 
before the start of the faculty appointment. 

Qualified applicants should send their re¬ 
sumes and the names and addresses of at 
least three references to: Chairman, Search 
and Screening Committee, Computer and 
Information Sciences Department, 301 
CSE, University of Florida, Gainesville, FI. 
32611; telephone number: (904) 335-8000. 

Closing date: November 6, 1989 or until 
positions are filled. University of Florida is an 
Equal Opportunity/Affirmative Action Em¬ 
ployer. This faculty search will be in compli¬ 
ance with Florida’s “government in the Sun¬ 
shine Law.” 


GEORGE MASON UNIVERSITY 
Faculty Positions in 
Computer Science 

George Mason University is located in 
Fairfax County, Virginia near the outstand¬ 
ing scientific, cultural, and touristic attrac¬ 
tions of Washington, DC, The university has 
made a major commitment to establish a 
School of Information Technology and Engi¬ 
neering (SITE) and maintain an outstanding 
academic and research program in the De¬ 
partment of Computer Science, as well as 
related research centers in software engi¬ 
neering, artificial intelligence, parallel com¬ 
putation/distributed systems, and computer 
vision/image processing. 

Tenure track and visiting faculty positions 
are available at all ranks, with the nominal 
date of appointments commencing Septem¬ 
ber 1990. Candidates for these positions 
must have an earned doctorate in a relevant 
field, along with professional accomplish¬ 
ments that are appropriate to the rank 
sought. They should be interested in both 
teaching and developing a strong sponsored 
research program. 

The relevant research and teaching areas 
of interest in Computer Science are: com¬ 
puter communications and networks, soft¬ 
ware engineering, parallel computation, 
computer vision/image processing, artificial 
intelligence, and distributed systems. 

Department faculty actively participate in 
and help support Departmental/School Re¬ 
search Centers in artificial intelligence (R. 
Michalski, Dir.), parallel computing (P. 
Wang, Dir.), image processing (A. Sood, 
Dir.), and software systems engineering (R. 
Fairley, Dir.). 

There are over 90 full-time faculty in 
SITE, and nearly 25 full-time faculty in Com¬ 
puter Science. There are numerous oppor¬ 
tunities for government and industrial in¬ 
teraction in this suburban high technology 
area, just 15 miles southwest of the Nation’s 
Capital. 

For full consideration, please send a 
detailed resume together with the names of 
four references, and other supporting 
material to: Professor Harry Wechsler, 
Chair, Recruitment Committee, Department 
of Computer Science, George Mason Uni¬ 
versity, Fairfax, VA 22030, or call at 
703-323-2713. Applications are sought by 
Feb. 1, 1990, and these will receive first 
priority. AA/EOE. 


UNIVERSITY OF CALIFORNIA 
AT RIVERSIDE 
Faculty Positions in 
Computer Science 

Applications and nominations are invited 
for tenured or tenure track positions in Com¬ 
puter Science beginning July 1, 1990 or 
later. Ph.D. and demonstrated excellence in 
research and teaching are required. Promi¬ 
nent senior candidates are especially en¬ 
couraged to apply. The program in com¬ 
puter science is growing rapidly, and is pro¬ 
jected to double in size in the next 4 years. 
The department has decided to concentrate 
in areas projected to be important in the 21st 
century, including algorithm design, parallel 
computation, computational logic, design 
automation, programming languages, com¬ 


puter architecture, and software engineer¬ 
ing. Three open rank positions are available. 
One is targeted to Computational Logic and 
another is targeted to Design Technology; 
the third is open as to area. This is an oppor¬ 
tunity to participate in shaping a developing 
program in computer science, with the ad¬ 
vantage of a close liaison with a well- 
established mathematics department. 

Riverside is a rapidly growing community 
of over 200,000, one hour from Los 
Angeles; an independent metropolitan 
center, not a suburb. The city has its own 
Philharmonic and Civic Light Opera. Skiing 
is available from November to April less than 
1 hour away in the San Bernardino moun¬ 
tains. Housing is far less expensive than in 
most other areas of Southern California. The 
Riverside campus of the University of Cali¬ 
fornia has an undergraduate enrollment of 
6700 and a graduate enrollment of 1400, 
and is expected to double in size by the turn 
of the century. Other major institutions, such 
as UC Irvine, UCLA, USC, UC San Diego, 
and Cal Tech, are within easy driving 
distance. 

Send au matenais including curriculum 
vita and the names of at least three refer¬ 
ences to: Professor Lawrence Larmore, 
Chairman, Computer Science Recruiting 
Committee, Department of Mathematics 
and Computer Science, University of Cali¬ 
fornia, Riverside, CA 92521. The pool of 
candidates will consist of all those whose 
completed applications are received by Jan¬ 
uary 8, 1990. If the search is not successfully 
completed from this pool, the pool will be 
enlarged to include all those whose com¬ 
pleted applications are received between 
January 9, 1990 and March 5, 1990. 

University of California, Riverside, is an 
Affirmative Action/Equal Opportunity 
Employer. 


UNIVERSITY OF CALIFORNIA, 
SANTA CRUZ 

Computer & Information Sciences at UC 
Santa Cruz invites applications for two posi¬ 
tions of Assistant Professor, effective July 1, 
1990. One position is in Computer Graphics 
(#194-890), the other is in Distributed 
Systems, Operating Systems, and Program¬ 
ming Languages, (*195-890). A Ph.D. in 
Computer Science or equivalent is required. 
Candidates must have demonstrated re¬ 
search potential, and will be evaluated on 
their research record, teaching, professional 
activities, potential for distinction, and letters 
of recommendation. Salary range: $44,200- 
$46,400. Send applications, including cur¬ 
riculum vitae with cover letter, publications 
and teaching evaluations, and 3 letters of 
recommendation, promptly to the following 
address: Chair, Computer Faculty Search 
Committee, Baskin Center for Computer 
Engineering & Information Sciences, Ap¬ 
plied Sciences Building, University of Cali¬ 
fornia, Santa Cruz, CA 95064. Applications 
must be received by February 1, 1990. If 
either position remains unfilled, applications 
received by April 1, 1990, will be con¬ 
sidered. Please refer to Position *194-890 or 
*195-890 in your reply. UCSC is an EEO/ 
AA/IRCA employer. 
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UNIVERSITY OF 
SOUTHERN CALIFORNIA 

Chair, Computer Science. The Computer 
Science Department of the School of Engi¬ 
neering, University of Southern California 
(USC), seeks a distinguished computer 
scientist with the vision and skill to lead a 
strong department and further strengthen it. 
The School of Engineering, with 170 faculty 
and 4,300 students, ranks 6th in the nation 
in sponsored research expenditures. The 
Computer Science Department has a full 
time faculty of 22, and a student body of 125 
Ph.D. students, 250 M.S. candidates, and 
200 undergraduates. The departmental re¬ 
search budget currently is $3M per year. 
Faculty research interests encompass the 
traditional areas of computer science, plus 
interdisciplinary, emerging fields such as 
robotics and neural computation. Comput¬ 
ing research support is provided by a large 
network of modern workstations, and vari¬ 
ous supercomputers are available through 
the network. More than 100 SUN worksta¬ 
tions are used for teaching. The department 
maintains close ties with the Electrical 
Engineering Department which has a strong 
Computer Engineering Group of 16 faculty, 
and with the Information Sciences Institute 
(ISI), an off-campus research facility of the 
School of Engineering. IST’s staff of 200 
conducts research on a broad spectrum of 
computer science topics. Southern Califor¬ 
nia has the highest industrial production in 
the nation. Opportunities for industry/uni- 
versity collaboration are excellent because 
much of the local industry is high-tech and 
computationally oriented. 

Please send nominations and applications 
to: 

Professor Aristides Requicha 
Chair, Search Committee 
Computer Science Department 
University of Southern California 
Los Angeles, CA 90089-0782 
Telephone: (213) 743-3805 
Net Mail: requicha@lipari.usc.edu 
Applications should include a resume and 
a list of professional references. USC is an 
equal opportunity employer. 


ASTEM, KYOTO, JAPAN 
Research Positions in CAD and 
Knowledge Engineering 

The newly established Advanced Soft¬ 
ware and Mechatronics Research Institute 
(ASTEM), Kyoto, Japan, invites applica¬ 
tions for research and research associate 
positions. Speciality areas include, but are 
not limited to, LSI CAD, 3D CAD, and 
knowledge engineering. For a research asso¬ 
ciate position, a candidate should be highly 
qualified and hold an MS in CS, EE, or re¬ 
lated fields; for a research position a Ph.D. is 
normally required. ASTEM provides an ex¬ 
cellent environment for research in Software 
Engineering and AI with unique Japanese 
software and dedicated SUN4 and SUN3 
workstations. 

ASTEM is located in Kyoto, the ancient 
beautiful city of Japan. 

Send resume to: Dr. Masanobu Matsuo, 
29121 Firthridge, Rancho Palos Verdes, CA 
90274; (213) 544-0855. 


UNIVERSITY OF OKLAHOMA 

Faculty positions in the School of Electrical 
Engineering and Computer Science at the 
University of Oklahoma. Three tenure track 
positions are currently available. One posi¬ 
tion is in the area of computer architecture 
and computer engineering; another position 
is in the solid state devices and optoelec¬ 
tronics area and the third position is in the 
communications, controls or signal process¬ 
ing area. Applicants should have a Ph.D. in 
electrical engineering and computer science. 
Applicants will be considered at the assistant, 
associate, or professor level. Consideration 
of applicants will begin October 1, 1989 and 
will remain open until the positions are filled. 
Send vita to T.E. Batchman, Director, 
School of Electrical Engineering and Com¬ 
puter Science, 202 West Boyd, Room 219, 
Norman, Oklahoma 73019. The University 
is an equal opportunity employer. 


ACADEMIA SINICA 
Taiwan, Republic of China 
Institute of Information Science 

Applications are invited for research posi¬ 
tion in Institute of Information Science, Aca¬ 
demia Sinica. Ph.D. in computer or closely 
related fields required. Demonstratable re¬ 
search ability necessary. Applicants for 
senior positions must have proven research 
record. All fields in computer science are 
welcome. 

The Institute offers a good reseach en¬ 
vironment. No duty of teaching. Facilities in¬ 
clude 2 VAX’s, many SUN, IRIS, and E&S 
workstations, and an easily accessible ETA- 
10Q supercomputer at Academia Sinica. 
Budget for a parallel machine is available this 

Interested people please send application 
to Dr. Y.S. Kuo, Acting Director, Institute of 
Information Science, Academia Sinica, Tai¬ 
pei, Taiwan 11529, Republic of China. 
FAX: (011-886-2) 782-4814. 


CLEVELAND STATE UNIVERSITY 

The Department of Computer and Infor¬ 
mation Science at Cleveland State Universi¬ 
ty has a tenure track position in the areas of 
distributed systems or software engineering 
and design. Responsibilities include teaching 
(two courses/quarter) & research. Salary is 
very competitive. Qualifications: Ph.D. in 
Computer Science, MIS, or a closely related 
field. Ph.D. candidates with substantial pro¬ 
gress on a dissertation will be considered. 
Close relationships to business, engineering, 
and other departments provide an environ¬ 
ment conducive to research and consulting. 
In addition to university computing facilities, 
the department has laboratories using VAX 
computers running UNIX, VMS, and state of 
the art software. Faculty offices are equipped 
with personal computers. Inquiries and vita 
should be sent to: Dr. James D. Schoeffler, 
Chairperson, Computer & Information Sci¬ 
ence Dept., Cleveland State University, E. 
24th & Euclid Ave., Cleveland, OH 44115. 
Equal Opportunity Erpployer, m/f/h. 


UNIVERSITY OF WISCONSIN- 
MADISON 
Faculty Positions 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
tenure and tenure-track positions. A Ph.D. 
degree is required, and successful candi¬ 
dates are expected to participate in both 
teaching and research activities. Applicants 
in all areas of computer engineering are in¬ 
vited to apply, but the following areas are of 
special interest: computer architecture, com¬ 
puter networks, VLSI and computer-aided 
design, microprocessor and minicomputer 
applications, real-time control and in¬ 
strumentation applications, and engineering 
applications of artificial intelligence. Rank 
and salary will be commensurate with qualifi¬ 
cations and experience. Send resume and 
names of three references to J. Leon 
Shohet, Chairman, Department of Electrical 
and Computer Engineering, University of 
Wisconsin-Madison, 1415 Johnson Drive, 
Madison, WI 53706, an equal opportunity/ 
affirmative action employer. 


UNIVERSITY OF CALIFORNIA, 
SANTA CRUZ 

Computer Engineering at UC Santa Cruz 
invites faculty applications for two positions. 

One Associate or Full Professor, with an 
application closing date of December 15, 
1989. The candidate sought should have 
strengths in two or more of the following 
areas: special purpose architectures and 
parallel environments, computer aided de¬ 
sign; graphics, real time systems, image pro¬ 
cessing, computer architecture, computer 
systems and languages, networks, and soft¬ 
ware construction (#141-889). Salary de¬ 
pending upon qualifications and experience. 

One Assistant Professor, with an applica¬ 
tion closing date of February 1, 1990. The 
position is in Visualization and Scientific 
Computing or Computer Graphics and 
Workstation Architecture (#174-890). 
Salary range: $44,200-148,800 (9 month 

A Ph.D. in Computer Engineering, Elec¬ 
trical Engineering, Computer Science or 
equivalent is required. Candidates for 
tenured positions must have a solid research 
record as evidenced by publications in 
technical journals. Candidates for non- 
tenured positions must have demonstrated 
research potential. All applicants will be 
evaluated on their research record, teaching, 
professional activities, demonstrated leader¬ 
ship in their fields, and letters of recommen¬ 
dation. Send applications, including cur¬ 
riculum vitae with cover letter, publications 
and teaching evaluations, 5 letters of recom¬ 
mendation (3 for Assistant position), 
promptly to the following address. Chair, 
Computer Engineering Faculty Search 
Committee, Baskin Center for Computer 
Engineering & Information Sciences, Ap¬ 
plied Sciences Building, University of 
California, Santa Cruz, CA 95064. If any 
position remains unfilled after these dates, all 
positions will remain open at the assistant 
level until April 15, 1990. Please refer to 
Position #141-889 or #174-890 in your re¬ 
ply. UCSC is an EEO/AA/IRCA employer. 
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CITY COLLEGE OF CUNY 
Computer Science 

City College invites applications from 
computer scientists committed to both teach¬ 
ing and research, preferably in central areas 
of computer science, e g. database, operat¬ 
ing systems, computer architecture, tele¬ 
communications, graphics, artificial intelli¬ 
gence, and parallel processing. Applicants 
must have a Ph.D. in computer science or a 
closely related field. Recent Ph.D.s should 
have research potential and teaching experi¬ 
ence; senior applicants should have an out¬ 
standing research and teaching record. Posi¬ 
tions are open starting with the Spring and 
Fall semesters of 1990. 

The Department offers the BS and MS 
degrees; the Ph D. degree is offered in 
cooperation with the CUNY Graduate 
Center. An active research program utilizes 
the computing facilities of the Department, 
the College, and CUNY. 

Positions will remain open until filled. 
Salary range is $40,390-$70,110 per aca¬ 
demic year. 

Applications, with vitae and names of 
three references, should be sent to Daniel D. 
McCracken, Chair, Dept, of Computer Sci¬ 
ences; CITY COLLEGE OF CUNY, Con¬ 
vent Ave. at 138th St., New York, NY 
10031. An AA/EEO Employer M/F/H/V. 


SUNY AT BUFFALO 

Department of Computer Science 
Chair 

Nominations and applications are invited 
for the position of Professor and Chair of the 
Department of Computer Science, to begin 
Fall 1990. 

We seek a distinguished scientist with a 
prominent research record to lead an ex¬ 
panding department. Candidates should be 
committed to excellence in research and 
teaching, be conversant in trends and issues 
in computer science, and be willing and able 
to pursue opportunities for strengthening the 
department. Salary will be extremely com¬ 
petitive, with a flexible research budget. 

SUNY-Buffalo is the largest and most 
comprehensive public university in New 
York and New England. The department 
currently has 14 tenured/tenure-track facul¬ 
ty (with plans to increase this number) and 3 
lecturers. There are approximately 130 
Ph.D. and M.S. students and 200 selectively 
admitted B.A./B.S. majors. The depart¬ 
ment is scheduled to move into a new build¬ 
ing in Fall 1991. All faculty are actively 
engaged in research, principally in: AI, 
parallel algorithms, software quality, sys¬ 
tems, and theory, and in interdisciplinary re¬ 
search programs in Advanced Scientific 
Computing, Cognitive Science, Vision, and 
with the National Center for Geographic In¬ 
formation and Analysis. 

A complete resume, with names of four 
references, and a description of current re¬ 
search should be sent to: Dr. William J. 
Rapaport, Computer Science Search Com¬ 
mittee, Department of Computer Science, 
SUNY-Buffalo, Buffalo, NY 14260 (rapa- 
port@cs.buffalo.edu). Application closing 
date: 1 January 1990 or until position is filled. 
SUNY-Buffalo is an EO/AA employer. 


GOVERNORS STATE UNIVERSITY 
Computer Science 

Applications are invited for three full-time 
tenure-track positions in computer science to 
contribute to an established B.S. degree pro¬ 
gram and to implement a newly authorized 
M.S. in computer science. Applicants with a 
Ph.D. in computer science or closely related 
area are preferred. A Ph D. is required for 
eventual tenure. Outstanding applicants with 
an M.S. in computer science will also be 
considered. 

The University seeks faculty with strong 
teaching and research capabilities in data 
communications, networking, operating sys¬ 
tems, software engineering, graphics, artifi¬ 
cial intelligence, and database development. 
Duties include teaching, research, and ser¬ 
vice. Salaries are competitive. 

Starting date: Negotiable 1/1/90-9/1/90. 
Please send a vita which includes identifi¬ 
cation of the teaching/research specialties 
and the names, addresses and telephone 
numbers of three references to: 

Jane Wells, Chairperson 
Computer Science Search Committee 
Governors State University 
University Park, IL 60466 
An AA/EO university. 


SENIOR PRODUCT 
DESIGN ENGINEER 

Manufacturer of industrial equipment in 
Greensboro, NC has immediate need for 
Software/Hardware Development Engi¬ 
neer. Responsibilities include product design 
and development of multi-processor, real 
time operating system for state-of-the-art, 
highly advanced machinery. Assembly lan¬ 
guages 8086/286/386 and C required. 
BSEE, 3-7 yrs. exp. with industrial back¬ 
ground pref. Competitive salary, attractive 
benefits and clear growth opportunity being 
offered. 

Resumes to: P.O. Box 93 
Landmark Sq. 

Stamford, CT 06901 


ROYAL HOLLOWAY 
BEDFORD 
NEW COLLEGE 
UNIVERSITY OF LONDON 
Chair of Computer Science 

Applications are invited for the above 
Chair at Royal Holloway and Bedford New 
College. The Department of Computer Sci¬ 
ence is part of the Science Faculty of one of 
the five designated science sites of London 
University. The location at Egham provides 
an attractive environment and opportunities 
for close industrial collaboration. Applica¬ 
tions (10 copies) should be submitted to the 
Personnel Officer, Royal Holloway and Bed¬ 
ford New College, Egham Hill, Egham, Sur¬ 
rey. TW20 OEX from whom further particu¬ 
lars should be obtained. 

The closing date for receipt of applications 
is 27th October 1989. 


UNIVERSITY OF ALBERTA 

Department of Computing Science 

Applications are invited for two tenure- 
track positions at the Assistant/Associate/ 
Full Professor levels. Responsibilities include 
research as well as teaching at both the grad¬ 
uate and undergraduate levels. Strong can¬ 
didates from all research areas will be con¬ 
sidered. 

This young and energetic department has 
recently undergone significant expansion 
and consists of 36 academic and 29 support 
staff. Current hardware support for research 
includes a time sharing network of MIPSM/ 
1000 and VAX 11/780L/C connecting 36 
Sun workstations and a large number of ter¬ 
minals. Well-supported laboratories exist for 
AI, database, distributed systems, graphics, 
image processing, programming languages 
and robotics research. Access to a Cyber 205 
is available. 

The current salary range is $C34,970 to 
$C80,000+ with the appointment level 
being commensurate with qualifications and 
experience. Send curriculum vitae, the 
names of three references and up to three 
reprints or copies of important publications. 
New Ph.D.’s should also include a copy of 
their transcript. Apply to: 

Dr. Paul G. Sorenson 
Department of Computing Science 
University of Alberta 
Edmonton, Alberta, Canada 
T6G 2H1 

Applications will be accepted until Janu¬ 
ary 31, 1990. 

The University of Alberta is committed to 
the principle of equity employment. 


HARVEY MUDD COLLEGE 
POSITION ANNOUNCEMENT 
IN COMPUTER SCIENCE 

Harvey Mudd College invites applications 
for a professor of computer science who can 
provide leadership and direction for its com¬ 
puter science program. This person must de¬ 
sire the challenge and opportunity to de¬ 
velop a unique program which builds on the 
existing strengths of the college in science 
and engineering. Qualifications for the posi¬ 
tion include a doctorate in computer science 
or in a related field with computer science ex¬ 
perience, demonstrated commitment to ex¬ 
cellence in teaching, a willingness and ability 
to participate in curriculum development, 
and significant professional experience, in¬ 
cluding research and/or the supervision of 
industrially-sponsored projects in computer 

Harvey Mudd College, one of the nation’s 
most selective undergraduate colleges of 
engineering and science, is a member of the 
Claremont Colleges. The college is an equal 
opportunity/affirmative action employer. 
Please send resume and names of four refer¬ 
ences to: 

B. Samuel Tanenbaum 
Dean of Faculty 
Harvey Mudd College 
Claremont, CA 91711 
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CARNEGIE MELLON UNIVERSITY 
Software Engineering Institute 
Designing the Future of 
Software Engineering Education 

The SEI Software Engineering Curricu¬ 
lum Project provides a unique opportunity 
for educators to work in an environment 
where high-quality education is the first and 
only priority. The project is designing under¬ 
graduate and graduate software engineering 
curricula for the 1990s and beyond, creating 
educational support materials, and promot¬ 
ing the growth of software engineering edu¬ 
cation through conferences and workshops. 

We are seeking an innovative educator to 
join our technical staff. Qualifications include 
at least three years of college or university 
teaching experience in computer science, 
superior oral and written communication 
skills, and a strong commitment to software 
engineering education. 

The Software Engineering Institute is dedi¬ 
cated to the rapid advancement of the state 
of the art and practice of software engineer¬ 
ing. The Institute is part of Carnegie Mellon 
University, one of the world’s most stimulat¬ 
ing intellectual environments for computing 
professionals. The SEI technical staff enjoy 
outstanding computing resources, substan¬ 
tial administrative, research, and document 
production support, and competitive salaries. 

To apply, please send a resume or curricu¬ 
lum vitae to Sally Miller, Software Engineer¬ 
ing Institute, Carnegie Mellon University, 
Pittsburgh, Pennsylvania 15213. 

Carnegie Mellon University is an equal 
opportunity-affirmative action employer. 
The Software Engineering Institute is spon¬ 
sored by the Department of Defense. U.S. 
citizenship or resident alien status required. 


UNIVERSITY OF SOUTH FLORIDA 
The Center for 

Microelectronics Research (CMR) 

The Center for Microelectronics Research 
(CMR) at the University of South Florida is 
seeking candidates for tenure track positions 
at the Assistant, Associate, or Professor 
level, with academic appointments in the 
Electrical Engineering, Computer Science 
and Engineering, or Physics Departments. 
Candidates must have an excellent record of 
research achievement in either of three 
areas: (1) electronic materials and semicon¬ 
ductor processing, (2) VLSI design, or (3) 
VLSI. Candidates are expected to have 
earned a Ph.D. degree and have at least the 
equivalent of five years of industrial ex¬ 
perience. Candidates are also expected to 
have sound communication skills, both ver¬ 
bal and written. Successful candidates will be 
expected to develop and conduct high level 
research as well as teach undergraduate and 
graduate courses in the appointing depart¬ 
ment. The Center for Microelectronics Re¬ 
search is a state funded research center 
which is part of the College of Engineering at 
USF and is currently housed in a new $10M 
engineering building. Areas of research 
which are supported by CMR include elec¬ 
tronic materials growth and characterization, 
semiconductor processing, computer-aided 


VLSI design, and integrated circuit test and 
characterization. In addition to the research 
faculty and graduate research assistants, 
CMR has a full time professional engineering 
staff to support and maintain laboratory 
operations. A new electronic materials labor¬ 
atory is currently under development to 
house recently purchased processing and 
characterization equipment, to include 
lithographic tools with deep UV exposure 
capability, conventional furnaces, LPCVD 
and PECVD tools, plasma and RIE etch 
systems, as well as after-glow and ECR 
systems, and a sputter tool with conventional 
and reactive sputtering capability. A variety 
of material characterization tools such as an 
FTIR/Raman spectrometer, an emission 
spectrometer, and a research ellipsometer 
have also been acquired. This is com¬ 
plemented by an integrated circuit design 
laboratory with more than ten Sun 3/60 
workstations, a color Versatec plotter, and a 
complete suite of commercial computer- 
aided design tools from Cadence Design 


Systems, CADAT, HILO, and others. A 
high performance integrated circuit test 
system is currently being procured. Research 
funding at CMR this year totals over $8M, 
with primary support coming from state and 
DOD funding sources, including a signifi¬ 
cant, multi-year research project in wafer 
scale integration sponsored by the Defense 
Advanced Research Projects Agency. CMR 
places strong emphasis on attracting and ex¬ 
ecuting high caliber, large scale, team- 
oriented research projects. Opportunities ex¬ 
ist for extensive interactions with industry 
both within and outside the state of Florida, 
and are encouraged. The University of 
South Florida is located in Tampa, one of the 
nation’s top growth areas with an expanding 
high technology industry base. The Universi¬ 
ty of South Florida is an affirmative action/ 
equal opportunity employer. Applications 
should be sent to Dr. Joseph Stach, Direc¬ 
tor, Center for Microelectronics Research, 
College of Engineering, University of South 
Florida, ENG 118, Tampa, FL 33620. 


KUWAIT UNIVERSITY 
College of Engineering and Petroleum 
State of Kuwait 

Kuwait University, College of Engineering and Petroleum, invites applications for 
posts of Professor, Associate Professor and Assistant Professor for September 1990 in 
the disciplines identified below. Maximum contract is for three years renewable sub¬ 
ject to the consent of both parties. The College also invites applications for visiting 
faculty at the minimum rank of Associate Professor for a minimum duration of one ac¬ 
ademic semester. All applicants must be in possession of a Ph.D. degree at the time Of 
application. Applicants must also be in possession of a B.Sc. degree in engineering. 
However, the Department of Electrical and Computer Engineering may consider 
applicants with a B.Sc. degree in mathematics or computer science. 

Department of Civil Engineering 

Surveying, Construction Management 
Department of Electrical and Computer Engineering 

a. Signal & Image Processing, Electronics (instrumentation). Machines 
and Power, Electronics, Computer Science and Engineering 

b. Visiting Professors for one year: Communications Systems, Power 
Systems, Machines and Power Electronics, Control Engineering, 

Computer Science and Engineering 

Department of Mechanical Engineering 

Thermal and Fluid Engineering, Fluid Mechanics, Mechanical Design and 
Stress Analysis, Computer-Aided Manufacturing, Electrical Applications in 
Mechanical Engineering 
Department of Chemical Engineering 

Desalination, Catalysis (Petrochemical industry). Polymer Engineering, 
Computer-Aided Design, Heat Transfer, Fluid Mechanics, Process Control 
Department of Petroleum Engineering 

Petroleum Production, Petroleum Reservoir Engineering, Drilling, 
Completion, Workover and Stimulation 
Department of Industrial and Systems Engineering 

Production and Quality Control, Operations Research, Simulation Systems, 
Human Factors Engineering 

Application forms and Conditions of Service may be obtained from: 

Kuwait University Office 
Att. College of Engineering 
3500 International Dr. NW 
Washington, DC 20008 

Completed application forms together with non-returnable copies of academic de¬ 
grees, graduate transcripts and representative publications must be sent by registered 
post directly to: 

Dean,Collegeo(Engineering& Petroleum 

13060 Safat 
Kuwait 
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IEEE COMPUTER SOCIETY 
Membership / Subscription Application 


BENEFITS 



Computer 

Computer comes automatically 
with membership. Written, 
reviewed, and refereed by 
experts, it features survey and 
tutorial articles covering the 
entire computer field, and 
departments such as new 
products, new product reviews, 
standards, and a reader forum 
called "The Open Channel." 
(monthly). 


Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books 

Receive discounts of up to 50°/o on over 600 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and design automation. Over 60 new titles 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 


Schedule of Fees 


To join: see item 1, 2, or 3. 

To subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, and expire or 
December 31. Choose full- or half-year rate schedules depending on date of 
receipt by the Computer Society as indicated below. Half Year Full Year j 
Mar 1-Aug 31 Sept 1-Feb 28 



I don’t belong to the IEEE and I want 
to join just the Computer Society 


□ $23.50 □ $47.00 : 


2 1 don't belong to the IEEE and I want 


to join both the Computer Society and the IEEE* 

I reside in Region 1-6 (United States). □ $47.50 

I reside in Region 7 (Canada). □ $43.50 

I reside in Region 8 (Europe, Africa, orthe Middle East) □ $43.00 

I reside in Region 9 (Latin America). □ $39.50 

I reside in Region 10 (Asia and Pacific). □ $38.50 


□ $95.00 

□ $87.00 

□ $86.00 

□ $79.00 

□ $77.00 


id the Computer Society may deduct $5 off the 


1 1 already belong to the IEEE and 1 want 
> to join the Computer Society. 

IEEE Member Number 


□ $ 9.00 

□ $18.00s 

( OPTIONAL PERIODICALS for new or current members 

IEEE Computer Graphics and Applications (3061) 6 □ $10.00 

□ $20.00 I 

IEEE Design and Test (3111) . 

6 

□ $10.50 

□ $21.00 1 

IEEE Expert (3151) . 

.6 

□ $ 9.00 

n $18.00 1 

IEEE Micro (3071) . 

.6 

□ $ 9.50 

□ $19.00 1 

IEEE Software (3121) . 

.6 

□ $10.00 

□ $20.00 1 

Transactions on Computers (1161) . 

...12 

□ $10.00 

□ $20.00 1 

Transactions on Knowledge and 

Data Engineering (1471) . 

.4 

□ $ 5.00 

□ $10.00 1 

Transactions on Parallel and 

Distributed Systems (1501) . 

.4 

□ $ 5.50 

□ $11.00 1 

Transactions on Pattern Anaysis and 

Machine Intelligence (1351) . 

....12 

□ $10.00 

□ $20.00 j 1 

Transactions on Software Engineering (1171) ... 

....12 

□ $10.00 

□ $20.00| 1 

Total amount remitted with this application 

$_ 

_ ! 


PRICES EXPIRE 12/31/90 


a □ Master Card □ American Express □ Eurocard 


Charge Card Number 


MAILING ADDRESS 


EDUCATION (highest level completed) _ 


REFERENCE (a. 


Return to: IEEE Computer Society, 10662 Los Vaqueros Circle, P.O. Box 3014 Los Alamitos, CA 90720-1264 USA. pci 

Residents of Europe mail to: IEEE Computer Society, 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM. 

Asian / Pacific residents mail to: IEEE Computer Society, Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107 JAPAN. 
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BOOK REVIEWS 


Editor: Guy Johnson, School ot Computer Science, Rochester Institute of Technology, Rochester, NY 14623. 


What Every Engineer Should Know About AI 

William A. Taylor (MIT Press, Cambridge, Mass., 1988, 331 pp., $25) 


If you are interested in a down-to-earth 
explanation of current information- 
systems jargon, this is probably the book 
for you. In 16 interesting chapters, the 
author covers the basic definition of arti¬ 
ficial intelligence, the results of AI re¬ 
search, the place of Lisp in AI, the evolu¬ 
tion of programming styles and so-called 
expert systems, logic programming, rule- 
and knowledge-management issues, 
Prolog, AI’s future, and Japan’s Fifth- 
Generation project. 

The text is sprinkled with specific ex¬ 
amples of successful AI and expert sys¬ 
tems. The style is practical, as befits a 
book addressed principally to engineers. 
Also, as a testimonial on the flysheet 
states, “The narrative style and spicy an¬ 
ecdotes make an otherwise boring sub¬ 
ject interesting and knowledgeable.” 

In Chapter 1, the author quotes a popu¬ 
lar definition of AI research — “design¬ 
ing computers that think as people do” — 
and asks, who needs that? Taylor’s defi¬ 
nition and view of AI is a long way from 
those of the discipline’s early founders; 
he states that, for engineering purposes, 
“AI is a few software ideas that work well 
enough for commercal use.” 

AI’s rapid acceptance over the past 
several years has been characterized by 
an eagerness to find an impressive handle 
to describe one’s life’s work. For example, 
much of what Taylor covers in Chapter 
14, “Getting Started in AI,” could have 
been (and was) written about informa¬ 
tion-systems development throughout 
the past 20 years: “hire outside help,” 
“train the in-house staff,” “involve the 
user,” “get management committed to 
support AI.” Sound familiar? It is what a 
lot of people have already been doing, 
and it seems to bring a lot of established 
practices and fields under AI’s umbrella. 

Somehow, for better or worse, AI has 
evaded the trap that snared operations re¬ 
search. OR was the wave of the future in 
the sixties. It employed a lot of very intel¬ 
ligent people. It encompassed a wide 
range of new exciting ideas. It promised 
the holy grail in terms of operating re¬ 
sults, bottom-line improvements, and 
bankable savings. But OR was impene¬ 


trable to management; all of its conclu¬ 
sions were so hedged about with con¬ 
straints and exceptions that management, 
which paid the bill, did not know how to 
respond. 

AI appears to have escaped such a fate. 
It has been equated with the development 
of a theoretical basis for business sys¬ 
tems. Business systems were formerly 
regarded as unstructured, disparate, 
poorly defined, and so on. AI, flourishing 
such terms as “expert systems” and 
“knowledge-based systems,” now legiti¬ 
mizes such systems as being part of a con¬ 
sistent body of knowledge. AI has taken 
over the field from information systems. 
What was useful and cost-effective be¬ 
fore AI’s acceptance is still useful and 
cost-effective, but AI now provides a 
handle that explains everything, is se¬ 
mantically easy to grasp, and promises a 
well-directed plan for the future. 

(But has AI truly survived? Or has it 
been so commercialized that the gurus of 
yesteryear can no longer recognize it or 
acknowledge it? I suspect the latter.) 

One point of caution: Taylor asserts 
that asking if Prolog will replace Lisp is 
unreasonable because the two are too dis¬ 
similar for either to replace the other. At 
the conclusion of Chapter 12, he states 
that “... the debate is irrelevant. Lisp is a 
programming language and Prolog is an 
expert system shell.” Faced with that as¬ 
sertion, a friend immediately accused the 
author of not having written any Prolog 
systems. The author might argue from his 
pragmatic base that a shell commonly in¬ 
cludes a user interface, and an expert sys¬ 
tem shell also includes an inference en¬ 
gine. So, isn’t it legitimate to think of 
Prolog in these terms? Maybe, but proba¬ 
bly not. Be cautious; the answer may de¬ 
pend on who you talk to. 

I recommend this book for an engi¬ 
neer’s technical book shelf. The chapters 
on such subjects as logic programming 
might be difficult to grasp, but AI, how¬ 
ever it develops, is a subject about which 
an engineer can ill-afford to be ignorant. 

James C. Hammerton 

Rochester Institute of Technology 


The Prentice Hall 
Guide To Expert 
Systems 

Robert A. Edmunds (Prentice Hall, 

Englewood Cliffs, N.J., 1988, 440 pp., 

$39.95) 

Edmunds has written a fine book. Un¬ 
fortunately, it’s not one that needed to be 
written. 

It seems as though there are hundreds 
of books on expert systems for a wide 
spectrum of audiences and levels. The 
Prentice Hall Guide To Expert Systems is 
intended for the management informa¬ 
tion systems professional who has not yet 
been exposed to expert systems, but it is 
hard to believe that such a person exists 
today, since expert systems have been 
featured in the scientific press for at least 
ten years and almost constantly in the 
popular press for the past five years. 

Nevertheless, this book is a gentle in¬ 
troduction to the subject. It covers the 
necessary material: expert system archi¬ 
tecture; expert system software, hard¬ 
ware, and development; expert systems 
vendors and their products; vendor, user, 
and system profiles; applications of ex¬ 
pert system technology; and getting 
started with expert systems. It also has a 
glossary, lists of publishers and periodi¬ 
cals, and an index. 

There is just nothing to distinguish this 
book from others that have already cov¬ 
ered the same ground. The material is 
complete and accurate, but stale and 
glossy. Donald Waterman did it first in 
his classic, albeit dated, A Guide To Ex¬ 
pert Systems (Addison-Wesley, 1986). 
Paul Harmon, Rex Maus, and William 
Morrissey have done it better in their 
book. Expert Systems: Tools and Appli¬ 
cations (John Wiley & Sons, 1988). 

If you have not yet been exposed to ex¬ 
pert systems, you could do a lot worse 
than buy this book. It is smooth, easy to 
read, and at the right level for its intended 
audience. However, I am still waiting for 
someone to write some new material, re¬ 
capping the experiences of the past ten 
years. 

Ernie Hughes 

Seattle Pacific University 
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Data Communications Principles & Problems 


George J. Moshos (West Publishing, 1989, 387 pp„ $49.25) 


This book is a valuable, competing text 
in a fundamental area of computer sci¬ 
ence that sorely needs more such books: 
data communications and networks. The 
text is definitely designed for upper-level 
undergraduate and first-year graduate 
computer science students, but it will also 
serve as a means for self-study. The book 
would be complemented by a teacher to 
coordinate transitions and provide addi¬ 
tional motivation. 

The nine chapters would constitute a 
single-term course. The first four chap¬ 
ters cover historical practices (including 
regulatory issues) and technical funda¬ 
mentals of signals and media propaga¬ 
tion. Although the author has “tried to 
remove the distractions” of mathematical 
intrusions, he fortunately has not added 
to that large body of work that lets stu¬ 
dents pretend that computer science is 
other than mathematics, both discrete 


and continuous. 

Chapter 5 is devoted to error-detecting 
and -correcting codes (both Hamming 
and CRC), and Chapter 6 to interfacing 
technology. The remaining three chap¬ 
ters introduce network protocols via the 
seven-layer ISO reference model and use 
that material in explaining LANs and cur¬ 
rent industrial standards. Five appen¬ 
dixes expand topics from the main text: 
spectral analysis, codes, Huffman com¬ 
pression, capacities, and queuing mod¬ 
els. 

This book is a jewel. It is attractive, 
with apt, well-executed illustrations, a 
typeface designed to be read, and a 
thoughtful design (perhaps the days of 
ugly books, however well rationalized, 
are almost behind us). Students will find 
it readable; each chapter includes a short 
summary and a key-terms list, and there is 
a 20-page glossary at the end. Also, the 


material is flexible enough that teachers 
should be able to avoid the common dis¬ 
aster of trying to teach another teacher’s 
course. Exercises accompany the 42 sec¬ 
tions (including appendixes), and there is 
a large selection of answers at the end of 
the book. 

Reading this book was like taking a col¬ 
lege course from a highly capable teacher 
who took great care to share underlying 
reasons and motivations — not just facts 
or principles — with his students. Data 
communications is not my field, but the 
book’s style communicates the author’s 
enthusiasm. My enjoyment studying the 
material made the learning process 
smoother and more pleasant than with 
most textbooks. The clarity is rare and 
most welcome. 

Peter G. Anderson 

Rochester Institute of Technology 


OSI Explained: End-to-End Computer Communications Standards 

John Henshall and Sandy Shaw (Ellis Horwood Ltd., West Sussex, England, 1988, 217 pp„ $34.95) 


Before beginning their book, Henshall 
and Shaw offer a quote from a Winnie- 
the-Pooh story, which states that some 
things need explaining twice before any¬ 
body knows what you are talking about. 
So it is with the ISO standards. 

The book starts out with an introduc¬ 
tion to the International Standards Or¬ 
ganization and its work on standards for 
Open Systems Interconnection. Those 
people only briefly acquainted with the 
OSI model and standards will find the in¬ 
troduction easily understandable. 

The book emphasizes the standards for 
the upper four layers of the ISO reference 
model: the transport, session, presenta¬ 
tion, and application layers. The net¬ 
work, data link, and physical layers are 


mentioned only briefly. As a student in 
the area of internetworking, I was disap¬ 
pointed at the lack of detail and emphasis 
given these three layers. However, the 
authors do state that they did not intend to 
emphasize the lower three layers, and 
they refer the reader to other texts that 
cover this material. 

The section on definitions and terminol¬ 
ogy is mandatory reading without which 
the rest of the book is difficult to under¬ 
stand. I also found helpful the glossary of 
acronyms and terms at the end of the book. 

Almost half the book is devoted to a de¬ 
tailed analysis of the upper four layers, 
including a functional description of 
each layer, the services it offers to the 
layer above it, and the method by which it 


exploits the layer below it to provide the 
service. The authors also discuss func¬ 
tional units, including which ones are re¬ 
quired for a layer and which ones are op¬ 
tional. One chapter demonstrates the 
steps carried out by each layer to estab¬ 
lish a connection, an FTAM remote file 
update, and an association release. Tim¬ 
ing charts and diagrams illustrate the ex¬ 
change of various protocol units for each 
layer description. 

To illustrate how OSI standards accom¬ 
plish a user function, the authors describe 
File Transfer (FTAM) and electronic 
mail (MOTIS/X.400), functions that are 
visible to end-users. Implementors and 
students of the application-level services 
will find this information very useful. 

The authors’ explanations are an excel¬ 
lent base for understanding the standards 
documents themselves. I admit to having 
read many of the descriptions twice, as 
the authors’ opening quote suggests. 

I recommend this book to anyone seek¬ 
ing an explanation of the standards asso¬ 
ciated with the ISO model. Books offer¬ 
ing this level of explanation are rare. It 
should be mandatory reading for those 
who will have to deal with the standards 
documents themselves. 

Gary M. Diana 

Eastman Kodak 


Reviewers wanted 


If you are interested in reviewing books for Computer, please submit your 
name, address, and a list of areas of interest and expertise to the Book Reviews 
Editor at the address below. Publishers should submit recent books for review 
consideration to the same address. 

Guy Johnson 

Department of Information Technology 
Rochester Institute of Technology 
One Lomb Memorial Drive 
Rochester, NY 14623 
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Data Networks: Concepts, Theory, and Practice 

Uyless Black (Prentice Hall, Englewood Cliffs, NJ, 1989, 877 pp., $39) 


This book is intended to be a reference 
and text for data communications profes¬ 
sionals and students. It meets these objec¬ 
tives well. Most texts that are sufficiently 
technical in their presentation of the 
physical elements of communication are 
written for an engineering audience. This 
book, on the other hand, targets a wide 
audience without trivializing the con¬ 
cepts or overwhelming the reader. The 
reader does not need a communications 
or electronics background to understand 
the book. The explanations are generally 
thorough and accompanied by appropri¬ 
ate diagrams. 

The book covers all aspects of commu¬ 
nications as represented by the Interna¬ 
tional Standards Organization’s Open 
Systems Interconnection model. A sig¬ 
nificant portion of the book deals with the 
physical aspects of communication, in¬ 
cluding a chapter on the telephone system 
and several chapters on the basic con¬ 
cepts of transmission and various media. 
The book could stand on its own as a text 
in this area, without the need for other ref¬ 
erences. The rest of the book covers the 
software associated with computer net¬ 
works, organized by the layers in the ISO 
OSI model. The chapter on personal com¬ 
puters and networks is something rarely 
seen in a text; it would benefit both stu¬ 
dents and professionals. 

The material is well written and pre¬ 
sented in an interesting way. There is 
quite a bit of historical background, 
which makes it more enjoyable. This can 
benefit a student or casual reader, but 
could be annoying for those who want the 
book strictly as a reference. 

The book would be suitable as a junior/ 
senior level text for computer science, in¬ 
formation systems, and engineering stu¬ 
dents in a one- or two-course sequence on 
communications and networks. The 
chapters seem fairly independent of one 
another, so teachers could also use the 
book in a one-term course, skipping 
around in the book to cover only specific 
topics. The end of each chapter offers a 
list of suggested readings, questions, and 
selected answers. Unlike some texts, the 
questions actually relate to material cov¬ 


The price of A History of Personal 
Workstations given in the July issue 
of Computer was in error. The cor¬ 
rect price of the ACM Press/Ad- 
dison-Wesley volume is $51.75, 
$46.58 for ACM members. 


ered in the chapter. 

The text compares favorably to Com¬ 
puter Networks (Andrew Tanenbaum, 
Prentice Hall, 1989); it contains much 
more detail on the physical aspects of 
communication and somewhat more 
about how actual networks perform. One 
weakness is the treatment of the data link 
layer and routing in the network layer. 
Some of the general concepts and termi¬ 
nology of the data link layer are buried in 
the examples of specific systems, which 
makes them hard to find. I prefer Tanen¬ 
baum’s treatment of the data link layer, 
especially his model protocols, which 
lead the reader from a trivial protocol 
through a simple yet robust one. Black’s 
book also does not offer much informa¬ 
tion on routing techniques, which would 
have to be augmented if this is to be used 
as a text. 

This book also compares well with 
Data and Computer Communications 


(William Stallings, MacMillan, 1988). 
Black’s text has less of an engineering 
tone and seems more complete in its treat¬ 
ment of the software needed at all levels. 

One bothersome aspect of the book is 
that Black does not give section numbers 
to sections within chapters. This makes it 
difficult to determine what section is a 
subtopic of another, so the internal or¬ 
ganization of the chapters is cloudy at 
times. 

Overall, I recommend the book to 
teachers and others looking for a compre¬ 
hensive but understandable book on com¬ 
puter networks and communication. If 
you want a book that doesn’t assume you 
are an electrical engineer, but that also 
doesn’t skimp on technical details, this 
may be it. It is a welcome addition to the 
vast array of books in the area. 

Margaret M. Reek 

Rochester Institute of Technology 


“Where Dale Carnegie ends, The Sales Athlete® begins.” 

—Tim Zagat 

Learn how to sell on the fast track with 
Kathy Aaronson, the executive sales 
expert and author of The Sales Athlete, 
whose training programs have inspired 
hundreds of thousands of “sales athletes.” 
Her new book, Selling on the Fast 
Track, is the simplest, most sophisticated 
and effective sales training program now 
available in book form. Over 300,000 
happily and successfully employed 
trainees attest to Aaronson’s immensely 
effective techniques. 
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A Member of The Putnam Publishing Group 
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The Symposium 

The Symposium is intended for engineers and computer scientists from aca¬ 
demia and industry who are designing and developing Computer-Based 
Medical Systems (CBMS). Reports about applications in progress are encour¬ 
aged. The Symposium provides an excellent opportunity for government 
regulators to interact with the medical device industry. Medical residents, 
biomedical engineering and computer science students who are working on 
medical computing projects are especially encouraged to submit papers de¬ 
scribing their work. 

The Program 

CBMS combines papers, presentations, discussions, and panels. Both contrib¬ 
uted and invited papers will be presented assuring an excellent and balanced 
program. All papers that are accepted and meet the publication deadline will 
be included in the Symposium Proceedings. Seven tracks related to Com¬ 
puter-Based Medical Systems are planned: 


Clinical Assessment and Risk Evaluation: real-time signal processing, 
database systems 

Medical Device Reliability and Safety: fault-tolerance, device testing, 
validation, software safety 

Communications and Image Processing: networking, compression, 
enhancement, modeling, simulation, PACS 
Health Effects and Risk Assessment of Environmental Agents: data 
management, assessment methods, exposure studies, simulation 
Cardiovascular Technologies: monitoring, imaging, bioimpedance 
measurements, microcomputer applications 
Artificial Intelligence & Neural Networks: theory, implementations, 
speech recognition, applications 

Communications Aids for Disabled People: environmental control, word 
processing, hearing impaired, vision impaired, standards 


Poster sessions, software demonstrations, and a tutorials program are also 
planned. Contributions to these parts of the program are also sought. 


Schedule for Contributed Papers 

Call for Papers Distributed: 

Paper Summaries Due: 

Notice of Acceptance: 

Camera Ready Papers Due: 


September 15,1989 
December 15,1989 
February 1,1990 
March 1,1990 


Paper summaries should be limited to two pages (typed, double-spaced) and 
should include the title, names of the authors, and the address and telephone 
number of the corresponding author. Send four copies of paper summaries 
and proposals for tutorials, posters, or software demonstrations to James N. 
Brown, Jr., Research Triangle Institute, Box 12194, Research Triangle Park, 
NC 27709 (phone -919-541-6994; fax -919-541-5945). 
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NEW FOR NETWORK ANALYSTS 



COMNET II.5 now predicts the performance 
of your SNA, DECNET, X.25, ISDN or other 
packet, message, or circuit switching network 


Free trial and, if you act now, free training 


C OMNET II.5 uses simulation 
to predict your network per¬ 
formance. You simply describe your 
network, traffic load, and routing 
algorithms. 

Animated simulation follows im¬ 
mediately-no programming. 

Easy-to-understand results 

You get an animated picture of 
your network. Routing choices and 
changing levels of network utiliza¬ 
tion are apparent. 

Your reports show response 
times, blocking probabilities, call 
queueing and packet delays, net¬ 
work throughput, circuit group 
utilization, and circuit group queue 
statistics. 

Computers with COMNET II.5 

COMNET II.5™ is available for 
most PC’s, Workstations, and 
Mainframes. 


Your network simulated 

You can analyze any computer or 
communication network which uses 
circuit, message, or packet switch¬ 
ing. Virtual-circuit or datagram 
operation can be modeled. 

Alternate-routing and adaptive 
shortest-path routing algorithms are 
built-in. 

Seeing your proposed network 
animated increases everyone’s 
understanding of its operation and 
builds confidence in your results. 

Immediate free trial information 

The free trial contains everything 
you need to try COMNET II.5 on 
your computer. If you act now we 
will include free training. 

Call Kelly Cox at (619) 457-9681, 
FAX (619) 457-1184. In Europe, 
call Richard Eve on (01) 528-7980, 
FAX (01) 528-7988. 


I Free trial offer 

i 

j Free trial-see for yourself how COM- 
| NET II.5 quickly answers communication 
network performance questions. 

I Limited offer-Act now for free training. 
| DSend information on your Special Uni- 
| versity Offer. 


| £l*_ 


| Telephom 


| Return to: IEEE C0IV 

CACI Products Company 
I 3344 North Torrey Pines Court 
I La Jolla, California 92037 

Call Kelly Cox at (619) 457-9681. 

| FAX (619) 457-1184. 

In Europe: 

I CACI Products Division 
I Regent House, 89 Kingsway 
London WC2B 6RH, United Kingdom 

Call Richard Eve on (01) 528-7980. 

FAX (01) 528-7988. 


COMNET II.5 is . 

























